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Chapter  1 


I . 1  I ntroduct i on 

There  are  several  reasons  that  the  lambda  calculus  is  impor¬ 
tant  for  designers  and  implementors  of  programmi ny  languages. 
One  of  the  first  uses  of  the  lambda  calculus  as  a  tool  of  pro¬ 
gramming  linguistics  occurred  in  the  mid  1960s  when  Strachey  and 
Landin  used  it  to  elucidate  the  semantics  of  Algol-60.  The 
lambda  calculus  was  picked  because,  as  we  shall  see,  it  has  the 
same  scope  rules  as  block  structured  languages.  This  allowed 
the  consequences  of  these  rules  to  be  studied  in  a  distilled  and 
simple  context.  In  particular,  this  allowed  the  implementation 
of  block  structured  languages  to  be  investigated  without  the  com¬ 
plexities  of  "real"  languages.  In  this  manual  you  will  see  both 
interpreted  and  compiled  implementations  of  the  lambda  calculus  - 
seminal  techniques  that  can  be  used  or  adapted  for  many  other 
languages.  For  instance,  the  cl osure  implementation  concept  is 
important  in  understanding  coroutines,  processes  and  the  “lazy 
evaluation"  techniques  discussed  in  Part  II. 

The  symmetry  and  simplicity  of  the  lambda  calculus  sets  a 
standard  against  which  all  languages  can  be  compared.  For 
instance,  the  essential  equivalence  between  formal  parameters  and 
declarations  in  the  lambda  calculus  suggests  a  solution  to  many 
problei.is  of  language  design.  This  has  been  used  in  several 
experimental  languages,  e.g.  Quest. 

Although  the  lai.ibda  calculus  is  capable  of  computing  any 
computable  function,  it  provides  a  model  of  computation  that  is 
much  closer  to  real  languages  than  most  other  such  models  (e.g. 
Harkov  algorithms,  Turing  machines,  recursive  functions).  It  is 
therefore  more  relevent  to  the  real  problems  of  language  design. 

The  programming  practices  and  modes  of  thought  used  with  the 
lambda  calculus  and  its  derivatives  (such  as  LISP)  have  formed 
the  foundation  of  functional  programmi ng  -  the  method  of  program¬ 
ming  recently  popul ari zed  by  Backus  and  characterized  by  a  high- 
level  applicative  programming  style.  The  lambda  calculus  is 
essential  for  an  understanding  of  the  design  and  implementation 
of  such  languages. 


Chapter  2 


T  .  ?  The  LanhH.a  Calculus 
T.^.l  calculus  (^etine^. 


'*'e  will  be  usinq  the  lambda  calculus  as  a  model  oc  comnuta- 
tion.  That  is,  we  will  be  usinq  the  lambda  calculus  as  a  wav  ot 
describinq  the  meaninq  ot  orograms  and  as  a  guide  to  the  imole- 
mentation  ot  orogramminq  lanauages.  ^  calculus  is  a  notation 
which  can  he  manipulated  mechanically  to  achieve  some  end.  "Cal¬ 
culus"  is  the  Latin  word  tor  "pebble"  and  is  derived  trom  the 
tact  that  people  used  to  do  arithmetic  by  maninulating  pebbles. 
("Calc"  is  the  Latin  word  for  "limestone"  and  is  also  the  basis 
tor  words  such  as  "calculate".)  You  are  nrohably  familiar  with 
the  differential  and  integral  calculi.  In  these  it  is  oossible 
to  manipulate  formulas  according  to  the  rules  ot  integration  and 
di tferentiation  to  get  results  that  would  otherwise  have  to  be 
derived  by  solving  complicated  limits.  You  may  also  be  familiar 
with  the  nropositional  and  oredicate  calculi.  In  these  certain 
forms  of  deductive  reasoning  can  be  oerformed  bv  the  mechanical 
naniDulation  of  symbols. 

The  reason  for  develooing  a  calculus  is  that  by  reducing 
some  orocess  to  a  set  of  simple  mechanical  rules  one  decreases 
the  chances  of  making  an  error.  Of  course,  the  fact  that  the 
rules  of  a  calculus  are  mechanical  and  strictly  defined  makes 
them  ideal  for  manioulation  bv  comouter.  The  lambda  calculus  is 
a  calculus  which  models  (mimics)  the  process  of  comoutation 
itself,  'Jnder  the  now  aenerally  accented  definition  of  comnuta- 
bility,  it  has  been  shown  (by  Monzo  Church,  the  inventor  of  the 
lambda  calculus,  and  Man  Turing)  that  anything  that  can  be  done 
on  any  computer  can  also  be  done  in  the  lambda  calculus  (althouch 
nerhans  very  inefficiently). 

1.7.2  bound  variables  def i ned . 

One  of  the  central  ideas  of  the  lambda  calculus  is  that  ot  a 
bound  variable  (sometimes  called  a  dummy  variable)  .  i^^ound  vari¬ 
ables  are  common  in  all  mathematical  notations,  for  instance,  in 
the  summation 


0. 

i  =  l 


o  f 


the 


•  :  • 


is  the  bound  variable. 


It  is  a  characteristic 


bound 


Por  instance. 
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variables  that  it  (doesn't  natter  what  thev  are. 


I  ^ 

k  =  i 


■< 


neans  exactlv  the  sane  t^^inq  as  the  orevious  sumnatian. 
larly.  the  inteqral  of  x'-3x  with  resoect  to  x: 

^x^-3x  (^x 

n 

is  the  same  as  the  integral  ot  with  resoect  to  u: 

'fu^-3u  f*ij 
f} 

In  set  theory,  the  set  of  all  x  such  that  x>^0  is  the  same  as 
set  of  all  n  such  that  n^h: 

{xlx>0}  =  {n!n>0} 


Mso,  a  proposition  such  as  "for  every  x,  x+l>x'’: 

Vx{  x+i>x  1 


is  the  same  as  the  proposition  "for  every  y,  v+l>y'': 

Vyf  y+l>y  } 


i  m  i  - 


the 


In  the  following  examples  the  bound  variables  are 
riqht. 


listed  on  the 


xoression 


MQunn 
''at  iahle 


Verh?ilization 


Che  sun  cor 


H  f  X --  3x  )  /c^  X 


the  orof^uct  tor  i  cron 


the  derivative  with  lesoect 


the  derivative  with  resoecc  to  v  or 


the  inteara' 


the  set  oc  all  x  such  that 


there  exists  a  y  such  that 


any  x  such  that 


the  uniciue  v  such  that 


T.7.3  bound  and  tree  occurrences ,  and  scooe . 

Two  ideas  that  will  be  verv  useful  to  us  are  bound 
occurrence  and  t' ree  occurrence.  Consider  the  exnression 

i  ^ 

1  =  1  ^ 

"^he  occurrence  or  'i'  in  is  called  a  hound  occurrence  of 

the  variable  'j'.  It  is  bound  by  the  sumnation  ooerator  fX)  . 
which  is  called  the  binding  site  (or  just  binding )  or  this 
occurrence  of  '1'.  We  can  see  that  'j'  is  bound  by  noting  that 
we  can  change  it  to  any  other  variable  (exceot  'i')  without 
changing  the  neaning  of  the  expression.  ’^or  instance, 


Any  occurrence  of  a  variable  that  is  not  a  bound  occurrence  is 
called  a  tree  occurrence.  Tor  instance,  'i',  ' n '  and  'A'  all 
occur  free  in  tue  above  expression.  Clearlv,  it  we  change  a  free 
variable  we  have  changed  the  rneaning  of  the  expression: 
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■''otice  chflt  when  we  say  that  an  occurrence  of  a  variable  is  hound 
or  tree,  we  say  this  relative  to  some  expression.  '=’or  instance, 
'■i'  is  tree  in 


^ut  is  bound  in 


n 


^ ^  4  and 

j  =  i 


'=^imilarly,  'i'  is  free  in  the  above  expressions,  but  bound  in 


O. 

i  =  i 


(i  ! 


n=i 


The  bindinq  site  of  a  variable  determines  its  scope ,  which  is  the 
region  of  the  expression  over  which  that  variable  is  bound.  This 
region  is  usually  indicated  by  some  textual  convention,  such  as 
brackets  or  parentheses.  To  state  things  differently,  all 
occurrences  of  a  variable  which  are  in  the  scooe  of  a  bindina  of 
that  variable  are  hound  occurrences  of  that  variable.  The  fol¬ 
lowing  figures  exemplify  these  concents: 


scone  of  x 

I - ' - 1 

x>y  } 


bindino  /  free  occurrence  of  v 

site  of  X  bound  occurrence  of  x 


binding  . 
site  of  X 


scooe  on 


tree  occurrence 
bound  occurrences  of  x 


of 


y 


As  we  have  already  seen,  it  is  perfectly  meaningful  tor  scopes  to 
be  nested  within  other  scopes.  Some  examples  of  nested  scopes 
are  shown  below  (the  brackets  indicating  scooe  are  called  scooing 
lines)  : 
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i  =  l|  1  =  1.  ^ 


scone  ot  t 
_ I 


scone  ot  i 


fx  ^v^+xv  <^v  dx 
'n  'n;  , 


scone  ot  y 
_ 1 

scone  or  x 

We  can  summarize  these  ideas  as  follows: 

*  The  binding  site  of  a  variable  determines  its 

*  »in  occurrence  of  a  variable  is  hound  it  it  is 
of  a  binding  site  of  that  variable. 

*  An  occurrence  of  a  variable  is  free  otherwise 


scope . 
in  the 


scone 


^XRRri.SK?^  ; 


'='or  each  variable  occurrence  in  the  following  expressions, 
indicate  whether  it  is  a  binding  site,  a  bound  occurrence,  or  a 
free  occurence.  ^raw  sconing  lines  to  indicate  the  scone  ot  each 
binding. 


1. 

2. 

3. 

4. 

5. 

7  ^ 

3. 


{  n  I  n>m  1 
lx  sin (x/vl  dx 


rxlsinfyxldy  dx 
"h  "n 


x2  +  y2 


D. 

i  =  l  j  = 


Vx [X«7  =>  3y  (ye7  A  X  = 
{x!x>0}  U  {x|x<0l  = 


v+1  )  1 
(x  1X750} 


e 


■2 


sinh (x) 


T  .  ^  renamina  '^ound  variables. 


As  we  have  seen,  hound  variables  are  arbitrary.  This  is  one 
reason  they  are  often  called  dummy  variables ;  they  only  serve  to 
establish  a  connection  between  oarts  of  an  expression.  Roun'^ 
variables  are  the  oronouns  ot  mathematics. 

Chanqinq  a  bound  variable  to  another  variable  does  not 
change  the  meaning  of  an  expression.  For  instance, 

CL  !]X 

i  =  i  k  =  l 

both  mean  the  sum  of  the  j-th  column  of  the  matrix  A.  ‘^UDOose  we 
change  the  bound  variable  to  'j': 


This  sums  the  diagonal  of  the  matrix;  we  have  altered  the  meaning 
of  the  expression!  We  got  into  this  trouble  because  we  changed 
the  bound  variable  'i'  to  the  variable  'j',  which  already 
occurred  within  the  expression.  "^hus,  the  occurrence  of  'j'  in 
A,  j  became  acc  idently  bound .  '^his  is  called  a  collision  of  vari¬ 
ables  .  The  conclusion  chat  can  be  drawn  from  this  is:  we  can 
change  a  bound  variable,  throughout  its  scope,  to  another  vari¬ 
able  only  if  the  latter  variable  does  not  occur  with  in  that 
scope. 


For  each  expression  determine  whether  the  indicated  change 
of  variable  alters  the  meaning  of  the  expression. 


1. 

f  X 1 x>y } ; 

change  x 

=  > 

2. 

{ X 1 x>y  } ; 

change  x 

=  ■> 

3  , 

^-xy)  ; 

change 

X 

4. 

same ; 

:  change  x  => 

y . 

5. 

Vx  r3y  (y>xl 1 ;  y  => 

X  . 

h. 

J  ;  y  => 

X  . 

7. 

sinh (x)  = 

gx-e-x 
- 2 - ' 

X 

-  12  - 


'J  fel  sin(e)=n  ^  ;  e  =>  ti. 
fxlx>n}  U  fylv<01;  V  =>  X. 

10.  ^  A ;  +  ;  i  =>  i  . 

i=l  ^  j=l  ' 

a  IX 

11  .  i'  ,'i.  j  =■>  i  . 

1.2.5  function  definition . 

'''hen  bound  variables  are  used  in  function  definitions  the'/ 
are  often  called  formal  parameters .  ^’or  example,  in 

f  (x)  =  x^-“3x 

'x'  is  the  bound  variable  or  formal  Parameter.  This  is  different 
from  the  previous  examples  of  bound  variables  in  that  the  bound 
variable  and  the  function  name  are  tied  toaether.  The  lambda 
calculus  Provides  a  notation  for  functions  which  does  not  have 
this  Problem.  For  instance,  in  the  lambda  calculus  the  function 
f  can  be  written 

>xfx’-3x} 

Ithe  >  is  a  lambda),  which  can  be  read  "that  function  which  takes 
anv  X  into  x^-“3x.”  In  the  lambda  calculus,  if  we  have  defined 

f  =  >x{x^'*3x) 

and  then  we  ask  the  value  of  ’ffS)',  we  can  find  it  by  substitut¬ 


ing  ’  5  ’  for 
start  with 


throughout  its  scope.  More  specifically,  we 


'''hen  we  substitute  >,x{x^-3x}  for  'f'  we  get 

/x{x^-3x}  (5) 

Mow,  we  replace  this  expression  by  a  copy  of  the  body  of  f 
(namely  x“-3x)  in  which  everv  free  occurrence  of  'x'  is  replaced 
by  '5' ; 

5’^-3'5  =  25-15  =  in 


This  is  called  the  "copy  rule”  for  function  evaluation  because 
the  invocation  'f(5)'  is  actuallv  replaced  by  a  copy  of  the  body 
of  the  function  with  its  parameter  textually  substituted,  i.e. 
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■  52-3 ‘S'. 

1.2.6  syntax  or  the  ..anbda  calculus . 

The  lambda  calculus  has  a  very  simple  syntax.  Lambda 
expiessions  are  composed  ot  the  symbols  '}'/  ')' 

and  variable  names,  put  together  according  to  the  loliowing 
rules: 

(1)  It  'x'  IS  a  variable  and  'S'  is  an  expression  or  the 
lambda  calculus,  then  '>x{S}'  is  an  expression  ot  the  lambda  cal¬ 
culus,  called  an  abstraction.  We  call  'x'  the  binding  ot  the 
abstraction  and  '£'  the  body  ot  the  abstraction. 

(2)  It  'F'  and  'S'  ate  expressions  ot  the  lambda  calculus, 
then  'F(E)'  is  an  expression  ot  the  lambda  calculus,  called  an 
application.  We  call  'F'  the  operator  ot  the  application  and  'S' 
the  operand  ot  the  application. 

(3)  It  'S'  IS  an  expression  ot  the  lambda  calculus,  then  so 
IS  '  (S)  ' . 

(4)  It  'x'  IS  a  variable,  then  it  is  an  expression  ot  the 
lambda  calculus. 

(S'  The  only  lambda  expressions  ate  those  described  in  (1) 
to  (4)  . 

To  permit  mote  raeaningtul  examples,  we  will  sometimes  allow 
additional  types  ot  expressions  within  out  lambda  expressions, 
such  as  conventional  arithmetic  expressions  (e.g.  '3+x'). 

The  way  in  which  we  have  described  the  svntax  ot  the  lambda 
calculus  will  form  a  model  tor  all  later  syntax  descr  i  ot  ions .  '*'6 

have  enumerated  a  set  of  Primitives  (the  basic  symbols  and  vari¬ 
ables'  and  have  described  a  set  of  constructors  or  formation 
rules,  which  will  yield  all  the  legal  expressions  of  the  language 
when  applied  recursively  to  the  primitives. 

EXERCISES: 

'»'hich  of  the  following  are  legal  lambda  calculus  expres¬ 
sions? 

1 .  X 

2.  ffx) 

3  .  >x{  f  (x'  ' 
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4 .  (g)  y 

5.  f (a) (b) 

6.  /x{f(x;}  (a) 

7  .  >vX{  L  (X)  }  (  >,x{x}  ) 

3.  f  g 
9  .  Ig (a)  } 
xO .  f { X  } 
ii.  fOx) 

1.2.7  aemantics  o t  che  lambda  calculus . 

In  a  previous  section  we  inLOtmally  discussed  evaluation  or 
expressions  oi  the  lambda  calculus  by  the  copy  rule.  In  this 
section  this  evaluation  is  denned  mote  exactly  through  two 
t  eduction  rules; 

1  ( t enaminq ) ;  one  expression  may  be  reduced  to  another  by 
cnanging  a  bound  variable  throughout  its  scope  to  any  other  vari¬ 
able  that  does  not  occur  within  that  scope. 

■2  (substitution)  ;  a  subexpression  or  the  totm  '/x{E}(A)'  may 
be  reduced  by  replacing  it  by  a  copy  or  S  in  which  all  tree 
occurrences  or  x  are  replaced  by  A,  provided  this  does  not  result 
in  any  tree  variables  or  A  becoming  bound. 

We  can  testate  the  renaming  rule  as  tollows;  An  expression 
'>.x{E}'  may  be  reduced  by  renaming  to  an  expression  '/ylF}', 
where  F  is  obtained  rtom  E  by  replacing  all  rtee  occurrences  or  x 
in  E  by  y.  This  is  only  allowed  ir  y  does  not  ocsjur  in  E.  For 
example,  suppose  we  wish  to  rename  x  to  u  in  '/x  { x“+2x+i  .  We 
do  tnis  by  changing  to  u  all  tree  occurrences  or  x  in  'x'‘+2x  +  i'. 
This  yields  '>u{ u^-2u+i }  ' .  This  reduction  is  symbolized: 

>vx{x^+2x  +  l}  =>  /u{u^  +  2u+i} 

Some  other  reductions  permitted  by  the  renaming  rule  are: 

/x(x}  =>  >,a{a}  =>  >,g{g}  =>  At{t} 

/x{/y{x(y)}}  =>  >>r{>,y{  t  (y)  1  }  =>  /rl/a{t(a)}} 

/x{x  +  i}  =>  >,u{u+i} 

/.)c{/y{x+y}  }  =>  /a{>y{a+y}}  =>  /a{>b{a+b}} 

Lets  consider  an  illegal  aoDlication  or  the  renanina  rule  in 
order  to  better  understand  its  restriction.  Sunoose  v/e  wish  to 
aoolv  the  renaming  rule  to 
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t  =  /x{  e'x  }  =  >,x{  ( 2 . 7  29  .  .  .  )  X  } 

bv  changing  x  to  e.  This  is  not  allowed  since  e  occurs  in 
'e’x'.  We  can  see  that  it  we  did  the  substitution  anywav  we 
would  change  the  meaning  ot  the  expression: 

t'  =  /e{  e‘e  }  =  >,ef  e^  1 

’^'ote  that  t  (1)  =  2.7i«?29...  v/hile  f'(l)  =  1;  t  and  t'  are  not  the 
same  function.  Renaming  x  to  y,  however,  would  not  change  the 
meaning: 

t"  =  Ayf  e-y  1;  f'fl)  =  2.718  29,,. 

The  renaming  rule  is  generally  needed  only  to  avoid  variable  col¬ 
lisions. 

EXERCISES: 


^DDly  the  renaming  rule  as  indicated,  or  state  that  its 
application  would  be  illegal: 

1.  >x(x};  change  x  =>  y. 

2.  /x{>y{x+y} 1 ;  change  y  =>  x. 

3.  >,x{t(x)};  change  f  =>  g. 

4.  /d{d+e};  change  d  =>  e. 

5.  /x{>y {x  (y) } } ;  change  x  =>  f. 

Mext  we  will  consider  the  substitution  rule.  The  expression 
'>xfx+l}(3)'  fits  the  form  required  by  the  substitution  rule:  it 
is  an  application  whose  operator  is  an  abstraction.  Renee,  we 
can  reduce  it  by  replacing  all  free  occurrences  of  'x'  in  'x+1' 
by  '3'.  The  result  is  '3+i',  Mow  consider 

>vx{  >,y  {x  (y)  ]  ]  (f  ) 

This  is  an  application  whose  operator  is  the  abstraction 

/xf  >vfx  (y)  }  1 

We  can  apply  the  substitution  rule  bv  replacing  by  'f'  all  free 
occurrences  of  'x'  in  '>.y{x{y)}'.  This  Produces: 


Xy { f  (y) } 
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To  better  understand  the  restriction  on  the  substitution 
rule,  tirst  consider  this  legal  substitution:  Supoose,  as  is 
usual,  that  e=2. 7182^1 ...  .  Let  f  =  Ax {>y { x+v} }  .  Then  we  can 
reduce  t(2e)(l)  as  tallows: 

t  (2e)(l)  ='>  >,x{Ay{x+y} }  (2el  (11 

=  >  Ay{  2e+y  }  (1) 

=  >  2e+l  =>  5.43. ..+1  =>  ‘^.^3... 

Mow  lets  look  at  a  slightly  ditferent  examole: 

f'(2e)(l)  where  f  =>,d{Ae{d+eU 

We  see  that  t'  is  the  same  function  as  f;  we  have  just  renamed  x 

and  y  to  d  and  e.  when  we  reolace  f'  by  its  value  we  aet 

Ad{>e{d+e>l (2e)  fil 

which  is  an  aoplication  whose  ooerator  is  the  abstraction: 

Ad  (Ae  f  d+e  1 1 

To  aoDly  the  substitution  rule  we  must  replace  all  free 
occurrences  of  'e'  in  ’Ae{d+e}'  bv  '2e'.  '»ut,  this  is  only 

allowed  if  it  does  not  cause  a  free  variable  of  ’2e'  to  become 

bound.  In  this  case  a  collision  does  occur,  since  'e'  is  tree  in 

’ 2e ’  but  not  in  'Aefd+e}'.  To  see  the  reason  tor  this  restric¬ 
tion  we  will  qo  ahead  and  perform  the  substitution.  The  result 
will  be  'Ae{2e+e}'.  This  has  changed  the  meanina  of  the  expres¬ 
sion;  a  fact  we  can  see  by  evaluating: 

Ae{2e+e}(l)  =>  2*1+1  =>  3 

Hence,  f ' (2e) (1)  =>  3 

although  we  know  the  answer  should  be  5.43....  How  do  we  avoid 
this  situation?  Since  bound  variables  are  arbitrarv,  we  simply 
rename  the  offending  bound  variable.  ’^or  instance,  we  can  rename 
' e '  to  ' c '  : 


Ad{Aefd+e}}  (2e)  (1)  =>  Ad  f  Ac  (d+c  } }  (2e )  f  1 1 


which  lets  us  proceed  with  the  reduction: 


Ad(  Ac{d+c}  }(2e)(11  =>  Ac{2e+cUl) 

=>  2e+l  =>  5.43. ..+1  =>  5.43... 


In  fact. 


this  is  the  major  use  of 


the  renaming  rule. 


EXERCISFS: 
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Oetetmine  it  the  substitution  rule  is  anolicable  to  each  ot 
these  expressions.  Tt  so,  reduce  the  expression  by  the  substitu¬ 
tion  rule,  tirst  aoplyina  the  renaminq  rule,  it  necessary. 

1  .  >x{x  (y)  }  (f ) 

2  .  >xf  >vy{x  (v)  1  1  (y) 

3.  t(3) 

.  /xf  >y{x(y)l  )(  Xz{v{z)}  ) 

5.  >.yfy*y}  (3) 

<=;.  >t{  t  (3)+f  M)  ^  (g) 

1.2.3  reduced  form. 

If  and  when  an  expression  is  reduced  to  the  extent  that  the 
substitution  rule  can  no  longer  be  applied  to  it,  it  is  said  to 
be  in  reduced  form.  Intuitively,  an  expression  is  in  reduced 
form  when  it  is  an  answer  (i.e.  it  is  done  computing).  The  fol¬ 
lowing  table  shows  examples  of  both  unreduced  and  reduced  expres- 
s ions : 


Moc  Reduced 

Reduced 

>x{x}  (v) 

y 

>y(f (y) } (a) 

f  (a) 

>>xf  Ay{x  (v)  }  }  (f  ) 

Ay{f  (y) } 

>.xfx}  (  >x{x}  ) 

>x{x} 

/xfx  (y) }  (  >x{x  (x) }  ) 

y  (y) 

In  each  case  above,  the  expression  on  the  right  is  the  reduction 
of  the  expression  on  the  left.  Mot  all  expressions  have  a 
reduced  form.  Consider  the  expression  Y  (Y)  ,  where  Y  =  >vx{x(x)}: 

Y(Y)  =>  >kx{xfx)}(Y)  =>  Y(Y)  =>  ... 

This  is  the  lambda  calculus  equivalent  of  an  infinite  loop. 

'=:xcqciSES; 

Decide  if  each  of  the  following  expressions  is  in  reduced 
form.  If  not,  then  reduce  it  to  reduced  form. 

1.  >f  {  t  (3)+f  (4)  }  f  >y{yy}  ) 

2  •  f  {  >vx{x+x}  ) 
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3  .  >xf  x<nl  (  >x{x  +  ll  ) 

>,x^x<n\  (  Ax^x+ll  (2)  ) 

1.2.^  mult inie  oaraneters  and  other  abbreviations . 

The  lambda  expressions  we  have  defined  have  only  one  bound 
variable.  '*ie  can  qet  the  eftect  of  two  bound  variables  by  nest¬ 
ing  the  lambda  exoressions,  for  instance: 

>x{>y{x+y}  1  (3)  {11 
=  >  >yf3+y}{l) 

=  >  3+1 

=  >  4 

Because  such  nested  lambda  exoressions  are  so  common,  we  allow 
the  following  abbreviations  (using  * => '  also  as  a  sign  of  abbre¬ 
viation)  : 

>kxy{x+yl  =>  AxOyfx+yl) 

F (3 ,1)  =>  F(3)  (1) 

These  abbreviations  are  the  usual  method  of  handling  multi- 
argument  functions  in  the  lambda  calculus.  Ot  course,  it  is  not 
normally  necessary  to  think  of  these  as  abbreviations;  we  just  do 
the  multinle  parameter  substitutions  directly,  e.g., 

if  f  =  >,xy{x+yl 
then  f  ( 3  , 1 ) 

/7V\ 

=  >  >xyfx+y}  (3,1) 

=>  3+1  =>  d 

In  exactly  the  same  way  we  will  allow  substitutions  involving  any 
number  of  oarameters,  including  none. 

/abc (ax^+bx+c } (9 , ^ , 1 )  =>  9x^+hx+l 

>{m+l} ()  =>  m+1 

As  we  have  seen  in  some  of  the  orevious  examples,  lambda  expres¬ 
sions  can  get  quite  large.  In  order  to  be  able  to  program  signi¬ 
ficant  functions  in  the  lambda  calculus  we  will  need  a  way  of 
attaching  names  to  lambda  expressions.  Therfore  we  will  allow 
rewriting  rules  ot  the  form; 

plusD  =>  >xfx>0} 

minuso  =>  >x{x<0} 

succ  =>  >,x{x+l} 

square  =>  >,x{x*x} 


F 
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Then  we  can  write,  tor  instance, 

minusD  (succ  (2) ) 

=  >  >.x{x<0}  (succ  (2)  ) 

=>  succ (2) <0 
=>  >x{x+l}(2)<0 

=>  2+l<0 

*>  3<0 

=  ■>  false 

r.2.10  the  Church*‘Rosser  property. 


In  the  above  reduction  we  reduced  the  outermost  aonlication 
first.  We  need  not  have  done  this,  tor  instance, 

minusD (succ (2) ) 

=>  mi  nusp  CXx  {  x+i  }  (2)  ) 

=>  minusp(2+l) 

=>  minusD{3) 

=>  >x{x<n}(31 

=>  3<0 

=>  false 


We  see  that  this  nroduces  the  same  answer.  It  is  a  nrooerty  of 
the  Dure  lambda  calculus  (called  the  Church-Rosser  prooerty)  that 
any  reduction  sequence  that  terminates  will  oroduce  the  same 
result.  It  is  important  to  know  when  a  lanauaqe,  or  a  part  of  a 
lanquaqe,  satisfies  the  Church-Rosser  orooerty  since  this  means 
an  ontimizinq  compiler  can  alter  the  evaluation  order  without 
effectinq  the  meaninq  of  a  proqram.  Since  some  of  the  extensions 
of  the  lambda  calculus  that  we  will  be  investigatinq  do  not 
satisfv  the  Church-Rosser  nrooerty,  we  will  adopt  a  standard 
order  for  reduction.  It  is  defined  by  the  rule:  don't  reduce  an 
application  until  its  arguments  are  already  in  reduced  form. 

STANDARD  RDD'JCTIGN  ORDER;  An  aoplication  is  reduced 
(by  substitution)  only  if  its  arguments  are  already 
in  reduced  form. 


EXERCISE ;  Reduce  to  reduced  form; 

>f{succ(f  (2)+l  '3)  )  }  Ox{square(x)+2}) 


EXERCISE ;  Suopose  the  following  definitions  are  given: 


-  20  - 


7efo  =>  >tc{c) 

One  =>  >tc{  t  (cM 
Two  ='>  /tc  f  t  ( t  (c)  )  > 

Three  =>  Ate { t  (  c (f (c) ) ) } 

sun  =■>  f/tc  ( t  ,M  ( t .  c)  )  }  1 

then,  reduce  to  reduced  torn  'sum  {Two, One)  '  .  ’''hat  is  this  equal 
to?  Ir  you  wonder  about  the  motivation  tor  these  definitions, 
then  try  reducing  ' Th ree (succ , 0) '  and  ' Two (succ , 3 ) ' . 


Chapter  3 


1.7  Th e  Extended  Lanbda  Calculus. 

1.3-1  Conditionals . 

Chs  laabda-calculus .  as  ve  have  been  usins  it  so  far,  is  not 
very  useful;  it  is  only  possible  to  define  functions  that  evalu¬ 
ate  strictly  in  order:  there  is  no  decision  naking  ability. 

Therefore  we  would  like  to  define  a  function  'if  such  that 
if^G.t.f)  =>  t  if  c  is  true  and  if(c,t,f)  =>  f  if  c  is  false, 
hence,  'true'  selects  't'  from  (t,f)  and  'false'  selects  'f  from 
't,f).  One  way  to  do  this  is  to  define  'true'  and  'false'  so 
that  true(t,f)  =>  t  and  fal3e(t,f)  =>  f.  Thus: 

true  =>  Atfit! 

false  =>  Atflf! 

Then  v/e  want  if(c,t,f)  =>  ■c(t,f),  where  c  reduces  to  true  or 
false,  so 

if  =>  Abtf{b(t,f)| 

To  see  how  this  works,  suppose  'x=.7'  returns  'true'  if  x  equals  y 


fal 

se' 

otherwise . 

Then 

2=0 

,  25.  3'’ 

) 

=  > 

if^ 

false , 

25. 

=  > 

Abt 

ffb(t,fi 

!  ■: 

false 

=  > 

fal 

3e(  25, 

ym  'i 

=  > 

Atf 

! f ! (  25 . 

"37' 

) 

=  > 

37 

we 

will 

nrogram 

th^ 

;  logi 

'not',  hot  is  the  simplest  since  it  just  negates  a  truth  value: 

not(true)  =>  false 
nof'false)  =>  true 

That  is,  if  X  is  true  then  not(x)  is  false,  otherwise  not(x)  is 
true.  This  can  be  directly  translated  to  the  lanbda  calculus: 

not  =>  Ax!  if(  X.  false,  true  )  ! 

The  'and'  function  is  defined  so  that  and(x,y)  is  true  only  if 
both  X  and  y  are  true.  This  is  summarized  in  the  following  truth 


We  can  see  tha't  if  x  is  true  then 
7.  and  that  if  x  is  false  then 
the  value  of  .7.  '-fe  can  translate 
calculus : 


and(x,y)  has  the  sate  value  as 
and(x,7)  is  false  regardless  of 
this  directly  into  the  lanhda 


and  =>  Axy!  if'  x,  y,  false  )  ! 


7  or  both 


Define  'or 
are  true. 


sc  that  or(x,y)  is  true  if  and  only 
That  is,  'or'  must  satisfy  the  truth 


if  X 
table 


n  T* 


DR 

true 

false 

true 

true 

true 

false  1 

true 

f  alse 

3how  that  your  definition  vorks  by  reducing  ’or(fal3e 
I. 3*2  Recursive  Definitions. 


true 


Dow  that  we  have  a  conditional,  we 
use'^ul  functions.  The  factorial  function 


can  define  sorie 
is  d e f i .n e d  so  t h a 


1!  =  d-3-2-1  =  24 

3!  =  3-2M  =  6 

D!  =  1 

or  in  general, 

n!  =  n'n-1  )rn-2)...(2)M  ^ 

The  factorial  can  also  be  defined  recursively  as  follows: 

n !  =  !  ,  if  n=0 

n( n-1 )  !  ,  if  n>0 

'Jsing  the  conditional  it  is  now  eas.y  to  define  a  function 
such  that  fac(n)  =  n!. 

fac  =>  )(nS  if(  n=0 ,  1  ,  n  '  fac(n-1  ''  'i  ' 


Consider  the  computation  of  fac(2;: 
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f  ac  ( 2 


=  > 

An! 

if( 

n=0,  1,  n-^-fac!"  n-1  )  ^  !  '2) 

=  > 

if' 

2=0. 

1 .  2*fac(2-1 ) ) 

=  > 

if( 

false.  1 ,  2*fac(l )) 

=> 

2*f ; 

ac  ( 1  ) 

=  > 

2  * 

An! 

if(  n=0 .  1,  n-*-fac(  n-1  )  )  f  ( 

=  > 

2  * 

if( 

1=0,  1 ,  1 *fac(l-1 )  ) 

=  > 

2  * 

1  * 

fac(O) 

=  > 

2  * 

1  ♦ 

An!  if(  n=0,  1,  n-^-fac ( n-1  )  ) 

=> 

2  * 

1  * 

if (  0=0,  1 .  0*fac(0-1 ) ) 

=  > 

2  * 

1  ♦ 

if(  true,  1,  O-^fac(-ld) 

=  > 

2  * 

1  * 

1 

=> 

=  > 

2  * 
2 

1 

To  keep  the  above  reduction  readable,  most  of  the  reductions 
associated  with  'if  have  not  been  shown.  Notice  that  in  the 
fourth  to  the  last  line  (the  last  line  with  an  'if  in  it'  if  we 
had  decided  to  reduce  the  argument  formula  0*fac(-1/  we  would 
have  started  a  never-ending  recursion.  That  is, 


2  ■* 

1 

♦ 

i  { 

0=0.  1,  0*fac(0- 

1  ^ ) 

=  > 

2 

♦ 

1  ^ 

if!  true,  1,  0-*’fac{-l)) 

=  > 

2 

* 

1  * 

if  (  true ,  1  .  0 

An!  if(  n=0. 

1  .  n*fac(n-i  ) '  !  (-1 

=  > 

2 

* 

1  * 

if  (  true ,  1  ,  0 

if(  -1=0,  1  , 

-1  A.*! !  if  (  •1=0 

,  1,  n-'*’facin- 

D)  )(-2)  )) 

=  > 

2 

* 

1  ^ 

if  (  true ,  1  ,  0 

if(  false,  1 

-1  if(  -2=0,  1 

.  -2*fac(-2-1 

^  ))) 

=  > 

process 

31  ay 

never  terminate! 

Church-Fosser  pro- 

perty  really  says  is  that  two  different  reductions  of  a  formula 
give  the  same  result  -provided  they  both  terminate .  For  this  rea¬ 
son  we  avoid  evaluating  any  arguments  of  'if'  that  we  don't  have 
to . 

Since  'if  is  such  a  common  function,  we  will  introduce  a 
special  notation  for  it.  This  is  just  an  abbreviation,  it  really 
adds  nothing  to  the  lambda  calculus.  Such  abbreviations  are 
often  called  "syntactic  sugar"  (because  a  little  "syntactic 
sugar"  helps  one  to  swallow  the  lambda  calculus).  For  simple 
'if s,  such  as  if(b,t,e)  we  will  write  [b->t!e],  which  is  read; 
"if  b  then  t  else  e."  For  nested  'if s.  such  as  if(b,  t,  iffc,  u. 
e )  ">  we  will  write 

r  b  ->  t  I  c  ->  u  I  e  ] 

and  so  forth.  This  can  be  read  "if  b  then  t  else  if  c  then  u 
else  e".  Nsing  this  notation  the  factorial  function  can  be 
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'  v'  r  ^  n 

fac  =■>  /n!  '^n=0  ->  1  I  n'fac(n-l)  ]  ’ 

Z.J.J  Primitives . 

We  have  seen  that  it  is  possible  to  iefine  in  the  lam 
calculus  Boolean  values  'true  and  false^ .  logical  connectiv 
’if’  expressions,  arithmetic  (sum),  and  even  numbers  themselves. 
P’nis  s’nould  lend  some  credibility  to  the  statement  made  earlier 
that  anything  that  can  be  done  on  a  computer  can  be  done  in  the 
lambda  calculus.  For  our  purposes,  there  is  not  much  point  in 
carrying  this  exercise  any  further.  In  the  future,  anv 
application-oriented  functions  that  we  might  need  ^such  as  arith¬ 
metic'  will  be  introduced  as  extensions  to  the  lambda  calculus. 
For  instance,  the  arit’nmetic  operations  might  be  introduced  by  a 
set  of  rules  like; 

3um( 1,1)  =>  2 

sum) 1,2)  =>  3 


or  in  general 

3um(m,n)  =>  m+n 

Ihis  way  we  have  an  application  independent  language  frameworV: 
formed  hy  the  lambda  abstraction  and  functio’n  application  svntax, 
and  a  flexible  set  of  application  dependent  primitive  operations 
which  we  can  define  as  the  need  occurs,  '"notice  that  again  we  are 
breaking  the  language  down  into  primitives  and  constructors .  In 
the  next  section  we  will  build  a  list  processing  language  by  com¬ 
bining  the  constructors  of  the  lambda  calculus  with  a  set  of 
powerful  list  processing  primitives.  We  will  find  that  many 
apparantly  different  programming  languages  are  really  juso 
sugared  versions  of  the  lambda  calculus  with  some  application- 
oriented  primitives  added.  The  following  chart  shows  some  primi¬ 
tives  that  might  be  included  in  languages  intended  for  numerical, 
list  processing,  string  processing  and  data  processing  applica- 
t ions , 


I 


rcy  a> 
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'  language 

constructors 

orimitives 

application 

independent 

aoplication 

dependent  ! 

numerical 

integers,  reals, 

+ ,  - ,  X .  ' ,  ... 

list  orocessing 

1 

>,xi  Bi  .  f  (a) 

lists  ,  atoms , 
f i rst ,  rest ,  cons ,  ... 

string  processingj 

Ax!  Bi  ,  f(a) 

strings,  characters, 
substr,  concat,  match.  ... 

data  processing  {  Ax|Ef,  f(aj 

1  i 

files,  records, 
move,  read,  write,  ... 

I.3-4-  Data  Tyoes . 


When  we  extend  the  lambda  calculus  with  new  primitives  we 
will  always  do  it  by  defining  a  set  of  data  values  and  a  set  of 
priaitive  operations  on  those  values.  Any  operations  we  wish  to 
perform  on  the  data  values  must  be  constructed  from  the  priaitive 
operations.  The  term  data  type  is  used  to  refer  to  a  set  of  data 
values  together  with  a  set  of  primitive  operations  on  those 
values.  ?or  instance,  the  data  type  integer  is  the  set  of 
integer  data  values: 

.  • . ,  -3,  -2.  -1 ,  0,  1 .  2.  3,  ... 


together  with  the  nriaitive  operations  on  those  values,  e.g., 

**)  /i  ^ 


Any  other  operation,  e.g.  squaring,  must  be  constructed  from  the 
given  values  and  primitive  operations: 


square 


An{  nxn  ! 


Similarly,  the  Boolean  data  type  is  composed  of  the  Boolean 
values : 

true,  false 

together  with  the  primitive  operations  on  these  values: 

not,  and,  or,  if,  =, 


1.3.5  The  List  Data  Type . 

In  this  section  we  will  define  the  list  data  type.  The  data 
values  are  called  lists  and  are  written  as  sequences  of  values 
surrounded  by  angle  brackets.  For  instance. 
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<5  3  16> 


is  a  list  containing  the  integers  five,  eisht  ani  sixteen,  in 
that  order.  Lists  can  have  any  nuaber  of  elements,  including 
one : 

<32> 

This  is  the  list  containing  only  the  integer  32.  Lists  can  also 
be  empty,  i.e.,  have  no  elements: 

<> 

Lhis  is  called  the  null  list .  Lists  can  contain  any  iata  values, 
for  instance, 

<5  ' cat '  false  1 . 6> 

is  a  list  vhose  first  element  is  the  integer  five,  vhose  second 
element  is  the  string  'cat',  vhose  third  element  is  the  Boolean 
value  false,  and  vhose  fourth  and  last  element  is  the  real  number 
1.6.  Lists  can  also  contain  other  lists,  for  instance, 


<5  <9  32>  3  16> 

is  a  1:  St  vhose  first  element  is  the  integer  five,  vhose  second 
element  is  the  list  <9  32>,  vhose  third  and  fourth  elements  are  3 
and  16.  Lists  can  be  nested  in  this  vay  to  any  depth. 

We  vill  define  three  important  primitive  operations  on 
lists.  The  function  'first'  returns  the  first  element  of  a  list. 

first(  <5  3  16>  )  =>  5 

first(  <<1  2>  <3  4>>  )  =>  <1  2> 

In  the  second  example  notice  that  the  first  element  of  <<1  2>  <3 

4>>  is  the  list  <1  2>.  It  makes  no  sense  to  apply  'first'  to  the 
null  list  or  to  an  atom ,  vhich  is  vhat  ve  call  things  that  are 
not  lists: 

first''  <>  )  is  meaningless 
first'  13  )  is  meaningless 

Hull  lists  and  atoms  don't  have  a  first  element. 

A  complementary  operation  to  'first'  is  'rest',  v/hich 
returns  all  of  a  list  except  the  first  element,  e.g.. 
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rest(  <5  3  1o>  )  =>  <3  16> 

rest(  <<1  2>  <3  4>>  )  =>  <<3  4>> 

rest(  <3>  )  =>  <> 

It  makes  no  sense  to  apply  'rest'  to  null  lists  or  atoms: 

rest(  <>  )  is  meaningless 
rest(  13  )  is  meaningless 

The  'first'  and  'rest'  operations  ta'^e  lists  anart;  we  need 
another  operation  to  put  them  together.  This  is  'cons'  (short 
for  "construot" ) ,  which  makes  its  first  argument  the  new  first 
element  of  the  list  which  is  its  second  argument.  Par  instance, 

cons(  5 .  <3  1 5>  )  =>  <531 6> 

con3(  <1  2>.  <<3  4>>  )  =>  <<1  2><3  4» 

cons(  <5>,  <3  16>  )  =>  <<5>  3  16> 

cons(  5,  <>  )  =>  <5> 

Notice  that  the  first  argument  to  'cons'  does  not  have  to  he  an 
atom,  although  its  second  argument  does  have  to  be  a  list: 

cons(  5,3)  is  meaningless 

The  meaning  of  'first',  'rest'  and  'cons’  is  summarized  in  the 
following  formulas.  In  these,  'x'  represents  any  data  value. 

firstv  <x  . . . >  )  =>  X 

rest (<x...>)  =>  <...> 

cons (x,  <...>)  =>  <x...> 

These  operations  can  be  combined,  for  instance, 

first(  rest(  <5  3  16>  )  } 

=>  fir3t(  <3  15>  ) 

=  >  3 

Hence,  first( rest(L) )  is  the  second  element  of  L. 

The  'cons’  operation  is  the  inverse  of  ’first’  and  'rest'. 
For  example,  since 

first(  <5  3  16>  )  =>  5.  a.nd 

rest(  <5  3  15>  )  =>  <3  15>.  and 

cons(  5,  <3  16>  }  =>  <53  1n> 


we  see  that 
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con3(  first^<5  3  ^6>),  r93^(<3  3  >S>)  ) 

=>  cons (  5 ,  <3  1 o>  ) 

=  >  <5  3  16> 

Thus,  the  following  identities  hold  'where  L  is  a  list  and  x  is 
anv  value): 

f  irst  ( cons ( X ,  L’' )  =  x 
rest  ( cons  ( X ,  I )  ">  =  L 

cons(  first(L)  ,  restd) )  =  Z,  if  1  is  non-null 

Another  primitive  that  will  he  useful  to  us  is  the  ecualit^;’  rela¬ 
tion.  For  instance. 

5=5  =>  true 

5=6  =>  false 

The  ecuality  relation  is  only  defined  for  atoms  (e.g.,  numbers, 
strings  and  Foolean  values'!;  its  use  on  lists  is  meaningless; 

5=<6>  is  meaningless 

The  meaning  of  the  equality  relation  is  summarized  by  the  fcllow'- 
ing  formulas,  in  which  ’a’  and  'b'  represent  different  atoms: 

a=a  =>  true 
a=b  =>  false 

There  are  only  two  other  functions  that  we  need  to  do  useful  list 
processing.  These  are  'null',  which  asks  if  a  list  is  empty,  and 
'atom',  which  asks  whether  something  is  a  list.  For  instance, 

null(  <>  )  =>  true 

nulK  <5  3  13>  )  =>  false 

null(  <<>>  )  =>  false 

The  list  <<>>  is  not  null  because  it  contains  a  sinale  element, 
namely.  the  null  list,  <>.  The  'null'  function  is  not  iefined 
for  atoms: 

null(5)  is  meaningless 

full  is  defined  by  the  following  formulas,  in  which  x  is  any 
value : 

null(  <>  )  =>  true 
null(  <x  ...>  )  =>  false 

The  'atom'  function  determines  whether  a  value  is  an  atom  or  a 
list,  for  example, 


atom''  5  '  =>  true 

aton(  <5  3  15>  ''  =>  false 

atoni(  <5>  '  =>  false 

atopi^  <>  )  =>  false 

The  'atom'  function,  which  is  meaningful  when  applied  to  any 
values,  is  defined  by  the  following  formulas,  in  which  'a' 
represents  any  atom: 

atom(  <...>  )  =>  false 

ato!n(  a  )  =>  true 

T’ne  list  data  tyne  is  summarized  in  the  following  figure. 

Data  Values: 

atoms:  1,  2,  ...,  'cat',  'hat',  true,  false,  .... 

lists:  <>,  <1  'cat’>,  <'call'  <'var'  'f'>  23> . 

Primitive  Operations: 


first ( 

<x 

...>  )  => 

X 

rest( 

<x  . 

. . >  )  => 

<  .  .  .  > 

cons  ( 

X,  < 

. . .>  ^  => 

<x  .  . 

a=a 

=> 

true 

a=a' 

=> 

false 

null  ( 

<>  ) 

=>  true 

null  ( 

<x  . 

. .>  )  => 

false 

atoa( 

a  ) 

=>  true 

atom( 

<  .  ,  . 

>  }  =>  f 

alse 

where  a  is  an  atom  and  x  is  a  list  or  an  a^om. 

Figure  1  .  The  List  Data  Type _ _ 

1.^.6  Recursive  Problem  Solving. 

In  order  to  better  understand  these  list  processing  opera¬ 
tions,  a  number  of  examples  will  be  presented.  First  we  will 
define  a  function  'sub'  such  that  sub(L,i)  is  the  i-th  element  of 
the  list  L.  For  instance, 

3ub(  <5  3  16  25>,  3  )  =>  16 

sub(  <5  <9  32>  16>,  2  )  =>  <9  32> 

since  <9  32>  is  the  second  element  of  <5  ^9  32>  16>.  How  are  we 
going  to  program  this  function?  The  way  to  solve  problems  li’xe 
this^^is  to  ask  what  subcases  of  the  problem  are  already  solved. 
In  the  case  of  'sub'  this  is  fairly  easy,  since  by  definition 


'sub'L.I')'  is  ;iu3t  the  first  elenent  of  L.  That  is, 

sub'L.I)  =>  first(L) 

The  next  step  in  solving  a  problem  such  as  this  is  to  finl  some 
way  to  reiuce  the  general  problem  to  the  subcases  that  are 
already  solved.  ilotice  that 

3ub(  <5316  25> ,  5  )  =>  15 
sub;  <3  16  25>,  2  ■  =>  16 

Hence , 

3ub(L.i)  =>  3ub(  rest(L),  i-1  ' 

V/e  have  reduced  the  original  problem,  3ub(L,i),  to  one  that  is 
closer  to  the  solved  problem,  3ub(L,l),  since  i-1  is  closer  to  1 
than  i  is.  We  now  have  two  cases,  just  as  in  the  factorial  exam¬ 
ple  : 

3ub(L,i)  =>first(L),  ifi=l 

3ub(L,i)  =>  3ub(  rest(l',  i-1  ),  if  i>1 

This  is  easily  translated  to  the  lambda  calculus: 

sub  =>  .Xui!  [  i  =  1  ->  first(L)  I  sub(  rest '  L ),  i-1  )  ]  ! 

We  will  try  this  on  sub(  <A  3  C  D> ,  3): 

3ub(<A  3  C  D>,  5) 

=  >  Al-i!  ^  i  =  1  ->  fir3t(L)  I  sub(  rest(L)  ,  i-1  )  1  !(<A  3  C  D> , 
=>  r  3=^ '->  first(<A  3  C  D>)  I  3ub(rest(<A  3  T  D>),5-1)  1 
=>  sub(<3  T  D> ,  2) 

=  >  "  2=1  ->  fir3t(<3  C  D>)  1  sub-restCO  C  D>),2-1)  1 

=  >  3ub( <G  D>  .  1  ) 

=  >  '■  1=1  ->  first(<C  DAI  I  sub(rest(<C  T>),  1-1)  j 

=>  first(<C  D>) 

=  >  C 

The  'sub'  function  is  30  useful  that  we  will  adopt  a  special 
"array  subscripting"  notation  for  it: 

A[i]  =>  sub(A,i) 

Thus,  a[i]  and  first(A)  are  the  same. 

Next  we  will  define  a  function  'append'  such  that 

append(L,N)  concatenates  the  lists  L  and  Id.  That  is, 


append(<1  2> ,  <3  4-  5>)  =>  <1  2  5  4  5> 


'lote  that  this  is  different  from  c:ons(<l  2>,<3  4-  5>)  which  would 
give  us  <<1  2>  3  4  5’^.  '-'le  will  use  the  same  problem  solvin 
technisue  that  we  used  with  'sub'  by  asking:  What  cases  o 
'append'  are  immediately  solvable?  Those  in  which  one  of  th 
lists  to  be  apoended  is  null,  for  instance, 

append(  <>,  <4  5  5>  )  =>  <4  5  6> 

In  general, 

append(  <>,  L  )  =>  L 
append(  L,  <>  )  =>  L 

'Text  we  must  investigate  'now  the  general  problem  can  be  reduced 
to  either  of  these  two  cases.  For  instance,  since  we  know 
append (<>,L)  is  L,  we  can  work  on  reducing  the  first  argument  to 
an  empty  list.  Suppose  we  wish  to  simplify 

append(  <2>,  <3  4  5>  ) 

'■‘le  know 

aor)end(  <>,  <3  4  5>  )  =>  <3  4  5> 

cons(  2,  <3  4  5>  )  =>  <234  5> 

so  we  can  see  that 

append^  <2>,  <3  4  5>  ) 

=>  cons(  2,  <3  4  5>  ) 

=>  cons(  2,  append(  <>,  <3  4  5>  )) 

!Tow  let's  consider  a  more  complicated  example: 

append(  <1  2>,  <3  4  5>  ) 

We  already  know  how  to  do 

append(  <2>.  <3  4  5>  )  =>  <234  5> 

so  all  we  have  to  do  is  reduce  the  new  case  to  this: 

aopend(  <1  2>,  <3  4  5>  ) 

=>  cons(  1 ,  <2  3  4  5>  ) 

=>  cons(  1 .  append(  <2>,  <3  4  5>  )) 

Summarizing,  we  have 

append(  <1  2>,  <3  4  5>  )  =>  cons(  1,  append(  <2>,  <3  4  5> 
append(  <2>,  <3  4  5>  )  =>  cons(  2,  append^’  <>,  <3  4  5> 


a> 
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Zt  shouli  be  aooarent  that 


the  general  case  is 


append(x,7)  =  Gons(  x[l],  append'  rest'x),  7 


Summarising,  vs  have  the  two  cases: 
append 'x, 7'  =>  7, 

append(x,7)  =>  consCx^l],  append ( rest  (  x'' ,7) )  , 


if  X  is  null 
if  X  is  non-nul 


This  can  be  eas 


I7  translated  to  the  lambda  calculus: 


append  =>  Ax7i 


null(x)  ->  7 

Gon3(  x[l],  append'  rest(x',  7',' 


! 


Vie  will  find  that  all  recursive  definitions  fit  this  pattern:  '1) 
a  stopping  condition  that  forms  the  base  of  the  recursion  and  (2) 
a  recursive  invocation  of  the  function  in  which  the  problem  is 
reduced  to  a  simpler  problem-  In  list  processing  the  stopping 
condition  often  takes  the  form  'null(...)'.  just  as  in  numerical 
functions  it  often  takes  the  form  '...=0'.  You  probabl7  will 
recognize  a  3imilarit7  between  recursive  functions  and  mathemati¬ 
cal  proofs  '07  induction.  This  similarity  simplifies  prooving 
that  recursive  functions  are  correct. 


It  should  be  mentioned  that  if  we  had  decided  to  reduce  the 
second  argument  to  the  null  list  rather  than  the  first,  we  would 
have  found  the  going  much  tougher.  The  list  processing  primi¬ 
tives  favor  working  on  the  beginning  of  a  list,  hence  the  first 
argument  of  ’append’.  This  sort  of  intuition  comes  from  practice 
with  using  the  primitives. 


Although  it  is  relativel7  easy  to  prove  that  ’append’  is 
correct,  we  will  convince  ourselves  by  working  the  reduction  of 
append(<1  2>.<3  1  5>  ■  • 


aoi3end(<i  2>,<3  A  5>) 

‘  ■  =>  r  null(<l  2>)  ->  <3  d  5> 


=  > 
=  > 

=  > 
=  > 
=  > 
=  > 
=  > 


I  cons'  <1  2>[l],  append'  rest(<1  2>),  <3 
consM  ,  append(<2>,  <3  4  5>)) 
con3(l,  [  null(<2>)  ->  ... 

I  Gons(<2>tlj. append (rest(<2>) .<3 
can3(l,  cons(2,  append(<>,  <3  4  5>)  )) 
cansil,  cons(2.  [null'O)  ->  <3  4  5>  1  •• 
cons(l,  cons'2.  <3  A  5>  )) 

Gonsd  ,  <2  3  4  5>  ) 

<1  2  3  A  5> 


A  ] 


As  final  example 
returns  ’true’ 

' i . e .  have  the  3 


,  we  will  define  the  function 
if  its  two  arguments  are  equal 
ame  structure).  (Recall  that 


'equal'  which 
atoms  or  lists 
only  works  on 


0 


t-(  C)  Cri  r-l  Crt  C  O  r-t 
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atoms,  hence  it  cannot  be  used  to  compare  lists.)  That  is 

equal(  <5  <3  16>  25>.  <5  <3  16>  25>  )  =>  true 

equal(  <5  <3  16>  25>,  <5  <8>  16  25>  )  =>  false 

As  in  the  previous  examples,  the  stopping  point  of  our  recursion 
will  be  those  cases  that  we  can  already  solve.  Then,  we  will 
attempt  to  reduce  the  general  case  to  these  simpler  cases.  A 

good  place  to  begin  in  any  list  processing  problem  is  the  null 

list,  and  this  is  the  case  here;  ali  null  lists  are  equal; 

equal(  <>,  <>  )  =>  true 


Another  good  place  to  begin  in  list  processing  is  with  atoms. 
This  is  particularly  true  in  this  case,  since  the  '=’  relation 
can  be  used  to  test  equality  of  atoms.  ?or  example, 

equal(5,5)  =>  5=5  =>  true 

equal(5,6)  =>  5=6  =>  false 

These  cases  can  be  written  more  generally; 

equal (x,y)  =>  true,  if  x  and  y  are  both  null 
squal(x,y)  =>  false,  if  x  or  y  is  null,  but  not  both 

equal(x,y)  =>  true,  if  x  and  y  are  atoms  and  x=y 

equal (x,y)  =>  false,  if  x  and  y  are  atoms  and  x^y 

equal(x,y)  =>  false,  if  x  or  y  is  an  atom,  but  not  both 


t  remains  to  reduce  the  general  case  to  these  solved  cases, 
onsiier  ' equal( x ,y ) ' ,  where  x  and  y  are  non-null  lists  (if  they 
ren't  then  the  problem  is  solved).  'Tow,  if  x  and  y  are  non-null 
ists,  what  are  the  conditions  that  must  be  satisfied  to  make 
hem  equal?  Clearly,  they  must  have  the  same  number  of  elements 
nd  each  of  their  elements  must  be  'equal'.  Since  both  lists  are 
on-null  we  'xnow  that  they  both  have  a  first  element.  Hence,  we 
an  compare  the  first  elements  with  'equal',  delete  them  from  the 
ists  and  then  compare  the  rest  of  the  lists  with  'equal'.  This 
is  the  simplification: 


equal(x,y)  =>  equal ( x[ 1 ] ,y[ 1 ] )  and  equal ( rest ( x ), rest ( y) ) , 
if  X  and  y  are  non-null  lists. 


to 


Putting  our  results  together  allows  a  direct  translation 
lambda  calculus; 


the 
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equal  =>  X 


xyf 

[  atoa(.x)  -> 
atoaCy) 


->  x=7  1  false  ] 
a'toa(y)  ->  false 
aull(x)  ->  null(y) 
null(y)  ->  false 

equal(x[ 1 ] .yf  1  ] )  ->  equal( rest( x) , rest^y) ) 
false  1  i 


fhe  ’atom'  tests  are  done  first  since  they  work  on  all  values 
(atoms  and  lists)  while  'null'  only  works  on  lists. 


ZXZRCISi;  '.'/rite  out  the  reduction  of  equal(<5  <3  16>  25>.  <5  <3 
1 6>  25>) . 

ZZCZRCI3S;  Define  the  function  'aemher'  such  that  aeaber(x,7'  is 
true  if  and  only  if  x  is  an  element  of  the  list  y.  That  is 
member(C,  <A  3  C  D>)  =>  true,  but  member(C.  <A  <3  C>  D>)  => 
false.  To  show  that  your  definition  works,  reduce  member(7,  <3  5 
7  9>)  . 


•S’VT'Dr' 

S3:  Suppose  y  is 

a  1 

ist  of 

pairs 

,  i .  e 

it 

<<a^ 

b.  > 

>  . 

<an 

b„» 

Define 

the  function  'assoc 

'( X  ,  y )  ' 

to 

be 

the 

firs 

x=a^ . 

For  instance, 

assoc(  'b ' ,  << ' a' 

1  > 

<'b'  3> 

<’ 

/-»  * 

5>> 

)  => 

assoc(  7,  <<1  0> 

<7  9 

>  <2  5> 

<'7 

3»  ) 

=  > 

3X3RCI33;  Suppose  x  and  y 

are  lis 

ts 

of 

the 

same 

foi 


wh  1  c  n 


1  i 


ist  or  oairs. 


For  instance, 


X  =  <x^ 

.7  =  <71  72 


•••  V 

,  _  •••  ^m^ 

a  =  <<bi  Ci><b2  02> 


<b„  c^» 


Define  ' pairli3(x ,y , a) '  to  be  the  list  resulting  from  adding 
pairs  <x^  y^>  to  the  front  of  a,  e.g.. 


«Xi  7i>  •••  <x^  y^>  <bi  ci>  •••  <b^ 

ZX3RCI33:  '-/rite  the  list  processing  primitives  (first,  rest, 
cons,  atom,  null)  using  linked  lists  in  Pascal  or  some  other 
language  you  are  familiar  with. 


1.3.7  Syntactic  Sugar . 

With  the  list  processing  primitives  we  really  have  a  small, 
but  usable,  programming  language.  In  fact,  the  language  we  have 
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is  very  similar  to  the  list  processing  language  LI'^P,  vhich  we 
will  be  discussing  later.  To  make  the  programming  language 
aspects  of  the  lambda  calculus  more  obvious  we  will  "sugar”  it 
with  an  Algol-style  syntax.  First,  we  will  replace  'X'  with 
'proc'  (for  'procedure'),  we  will  write  the  bound  variables  in 
parentheses  separated  by  commas  (i.e.  'xy'  becomes  '(x,yV),  '{' 
and  'i'  become  'begin'  and  'end',  ’(('  and  ']'  become  'if  and 
'endif,  '->'  becomes  'then'  and  '|'  becomes  either  'elsif  or 
'else'.  When  we  make  these  substitutions  in  the  'equal'  function 
we  get: 


Equal  =>  proc ( x , y ) 
begin 

if  atom(x)  then 

if  atom(y)  then  x=y  else  false  endif 
elsif  atom(y)  then  false 
elsif  null(x)'  then  null(y’^ 
elsif  null(y)  t’nen  false 

elsif  equal ( x[  1  ]  ,  y[  1  J )  then  equal (  rest(x),  rest(y'i; 
else  false 
endif 
9nd 


These  conventions  are  summarized 

in  the  following  diagram 

Axy 

=  > 

nroc ( X ,y ) 

(  .  .  .  I 

=  > 

begin  . . .  end 

r 

=  > 

1  X 

-> 

=  > 

'^en 

I 

=  > 

else  or  elsif 

] 

=  > 

endif 

We  will  use  the  acronym  ' ELC ' 

to 

refer  to  the  extended 

alculus ,  i.e.  to  the  cure  lambda  calculus  extended  by  the 
nteger,  Boolean  and  list  data  types  and  extended  by  the  syntac- 
ic  sugar  introduced  in  this  chapter. 


Approximate 
d if f erences 
chapter ) . 


quite  similar  to 
equivalences  are 
are  fairly  subtle 


the  programming  language  LISP, 
shown  in  the  following  chart  (the 
and  are  discussed  in  a  later 


k 


c-f  ly 
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orcaran  corresnoniin^  to  our 


;oual'  function  i 


(equal  'lambda  (x  y) 
( cond 

((atom  x)  (cond 


(atom  7 )  { 
T  "IL)}  ) 


\  \ 

eq.  X  7  ; 


( '  atom  y )  l.'li ' 

( (null  x)  (null  y)) 

((null  y)  ;rii; 

'(equal  (car  x)  (car  y')  'equal  'cdr  x'  (car  y' (  ' 


You  can  now  see  that  languages  can  have  very  different  an 
ances  even  though  they  are  the  same  underneath.  Ye  will 
that  most  programming  languages  are  sugared  versions  of 
lambda  calculus. 


is  has  two  advantages.  First,  it  reduces  the  size  and  com 
y  of  each  expression  so  that  they  can  be  more  easily  as 
lated  by  the  eye.  Second,  by  using  the  same  variable  'u'  in  both 
olaces  it  makes  it  more  obvious  that  it  is  the  same  identical 


Pi  U) 
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expression  in  both  places.  Now,  we  can  accomplish  the  same  thing 
in  the  lanbda-calculus .  In  particular, 


'ax+b 


reduces  to 


—J 

/ax+b 

1  m+n-^ 

(-Tt— 

1 

1  " 

1.7.9  local  declarations  in  the^  lambda  calculus  The  "where" 
notation  will  be  defined  as  a  "syntactic  sugaring"  of  function 
application : 

E  where  v=x  =>  >,vlzl(x) 

For  instance,  an  expression  such  as  this  (which  is  taken  from  the 
interpreter  discussed  later): 

eval(  f[l][2j,  append (  f[2],  con3(x,<>('  ) 'i 

could  now  be  written 

9yal(  f['][2],  NewFnv  ) 

where  NevFnv  =  append(  ffz],  cons(x,<>)) 

By  analogy  with  functions  of  several  argianents,  it  is  possible  to 
allow  compound  "where"  declarations: 

3  where  v, =X4  and  Vp=x^  and  ••• 

=  >  •  •  •  !  BTTxi  .x.,  ,7.  . 


‘1  ,  a2  t  .  .  .T 

For  instance,  the  expression  fragment 

elsif  e[l]  =  ' var '  then  af efZ ] ] [ e[3 ] j 

can  be  more  readably  written 

elsif  efl]  =  'var'  then  a[et)][vp] 
where  ep  =  eTzl 
and  vp  = 

There  is  another  way  in  which  mathematicians  use  variable  names. 
If  a  mathematician  is  going  to  use  an  expression  in  a  number  of 
following  lines  then  he  will  often  give  it  a  name  with  a  phrase 


such  as  "Let  u  be 


ax+b 


defined  in  the  lambda-calculus: 


Inis  style  of  definition  is  easil3r 
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let  v=x  iji  Z  =>  Avfzi'x) 
or  in  general 

let  =xi  and  Vo  =  Xp  and  • • •  in  Z 

=  >  Vp  •  (z!  Tx^  7X2  .  .  .  .  ■ 

Tnether  'let'  or  'where'  is  used  is  largely  a  natter  of  taste  an 
style.  In  general,  'where'  is  appropriate  when  'Z'  is  one  lin 
or  less  and  'lot'  is  appropriate  when  'Z'  is  nore  than  one  line. 
As  an  example  of  'let',  the  expression  fragment 

elsif  eM  ]  =  '  call '  then 

apply(  evai  '  e'. -)  ,  evlis(  rest  (  rest  (  e)  ;  ,  a)  ) 

can  be  written 

elsif  eH]  =  'call'  then 
let  closure  =  eval(ei2],a) 
and  actuals  =  eval(  re3t( rest's) ) ,  a)  in 
apply'  closure,  actuals  ) 

Zhe  use  of  names  such  as  'closure'  and  'actuals'  makes  the  pro¬ 
gram  more  readable,  albeit,  more  verbose. 

1. 3 •10  terminology  It  will  be  recalled  that  in  the  abstraction 
'Ax(Z|'  the  scope  of  'x'  was  defined  to  be  'Z'.  By  analog3/,  the 
scope  of  the  variables  defined  b^/  a  'let'  or  a  'where'  is  defined 
to  be  the  body  of  the  corresponding  abstraction.  For  instance, 
in  the  previous  example,  the  scope  of  'closure'  and  'actuals'  is 
the  following  line.  Zo  put  it  another  wa.^/.  the  scope  of  a  vari¬ 
able  is  t’ne  region  of  an  expression  over  which  it  has  meaning. 
Zhis  is  shown  in  the  following  diagrams: 

Avlz! 

— scope  of  'v' 


Z  where  v=x 


Zonsider  the  following  'let'  or  'where'  expressions: 

Z  where  v^  =X|  and  V2  =  X9  and  • • • 
let  v-|=x^  and  V9  =  X7  and  •••  in  Z 
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The  'v-=x^'  parhs  of  these  are  callei  def initions ,  declarations 
or  bindings  (because  they  bind  a  bound  variable  to  its  valued . 
The  'let'  and  'where'  constructs  themselves  are  called  blocks 
(particularly  in  languages  that  delimit  them  with  beain-end 
pairs).  These  constructs  occur  in  most  languages  although  in  a 
variety  of  forms.  For  instance,  the  Algol-6B  block 


begin  i=3;  j=m+1 ; 

i/3 

end 

means  the  same  as  the  lambda-calculus  block 

let  i=3  and  j=m+i 
in  i/j 

In  languages  that  use  begin-end  pairs  to  delimit  blocks,  like 
Algol-63,  the  declarations  ('i=3;  j=m+1 '  in  this  case)  are  col¬ 
lectively  known  as  the  head  of  the  block,  and  the  rest  of  it  is 
known  as  the  body  of  the  block.  Thus, 

•  bindings  (definitions,  declarations'! 


. begin  i=3;  3=ta+1  ;  i/j  end 

V  '  X 

'block  ^block  head 


head  block  body 


A  set  of  Pascal  declarations  such  as 

function  g(y: integer) :  integer; 
const  i=3; 

function  f(x: integer) :  integer; 

begin  f  :=  x'^i+l  end; 
begin  g  :=  f(.7)+1  end; 
begin  . , .  end 

means  the  same  as  the  lambda  expression 

let  g  =  proc(y)  begin 
let  i=3  in 

let  f  =  proc(x)  begin  x*i+1  end  in 
f(y''+1  end 

in  ... 

Of  course,  it  is  necessary  to  specify  types  in  Pascal  declara¬ 
tions,  but  not  in  lambda-calculus  bindings. 

As  a  final  example  of  blocks  in  the  lambda-calculus,  con¬ 
sider  the  lambda  expression 
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let  =ei  and  '^2~^2 
scope  of  'ooth  and 

-he  second  of  these,  which  is  called  a  comnpound  declaration .  is 
3uch  oiore  than  merely  a  shorthand  form  of  the  first.  Observe 
that  in  the  first  expression  e^  is  within  the  scope  of  v, . 
whereas  in  the  second  expression  the  scope  of  both  and  v.,  is 
just  e^ .  ?or  instance,  while 

let  i=3  in  let  x=A[i]  in  B 

has  the  same  effect  as 

let  x=a[3]  in  3 

the  expression 

let  i=3  and  x=a[i]  in  B 

is  illegal  (i.e.  doesn't  make  any  sense),  unless,  of  course,  'i' 
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is  bound 
clearly  by 
notation . 


in  some  surrounding  scope, 
translating  the  two  expressions 
The  first  becomes: 


This 

back 


can  be  seen  more 
to  pure  lambda 


r 

Aii  Axis)  (  A[i]  )  1(3'* 


bound  occurence  of  '  i 


scone  o 


■r  '  V  ’ 


scope  of 


which  is  correct,  and  she  second  becomes: 

AixiBi(  3,  A[i]  ^ 

scone  of  'i'  and  'x'  “^^^bound  occurence  of  ' 


which  is  not.  The  most  important  use  of  compound  declarations  is 
in  connection  with  recursive  declarations,  discussed  next. 


I. 3. ^2  recursive  declarations  Consider  a  declaration  such  as 

let  fac  =  nroc(n){  [n=0  ->  1  !  n'*’fac(n-1  )  ]  ! 

in  B 
I _ I 

'^scone  of  'fac' 

This  is  illegal,  as  we  can  see  by  nutting  it  in  pure  lambda  nota¬ 
tion: 

>  1  I  n*fac(r.-l)]  !  ; 

unbound  occurence  of  'fac' 

The  recursive  occurence  of  'fac'  is  unbound.  This  is  because  the 
value  on  the  right  of  a  binding  is  evaluated  in  the  surrounding 
environment.  This  is  clearly  an  unsatisfactory  situation. 
Although  there  are  ways  of  handling  recursive  definitions  in  a 
purely  applicative  way,  they  involve  complicated  mathematics  and 
so  will  not  be  discussed  here.  Instead,  the  technique  to  be  used 
will  require  some  of  the  imperative  facilities  discussed  in  the 
next  chapter.  Although  the  actual  technique  to  be  used  will  not 
be  described  until  the  next  chapter,  recursive  definitions  will 
be  used  in  this  chapter. 

A  declaration  of  the  form 


A  fac !  3  1  (  Ani  I"  n=0  - 

I _ I 

scone  of  ' fac  ' 
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let  rec  v=e  in  B 

l_ _ 1 

scope  of  'v' 

is  called  a  recursive  declaration  (or  definition  or 
because  the  scope  of  'v'  includes  'e'.  fherefore  ’e' 
use  of  'v'.  Similarly,  compound  recursive  declarations 
defined  so  that  in 

let  rec  v^  > 
and  rec  vp  =  eo 
and  ...  in ' 3~  ! 

^scope  of  V4  ,  V2 ,  ’  ■  • 

he  scopes  of  v^  ,  Vp ,  ...  include  ,  . .  Shis  al] 

efinition  of  mutually  recursive  functions,  for  instance; 

let  rec  Bval  =  proc(e,a)!  ...  applyf . . . )  ...  } 
and  rec  Apply  =  proc(f.xH  •••  evai(...)  ...  ] 

in  ... 


b inding) 
can  make 
will  be 


ows  the 
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Chapter  4 


I . 4  Implementing  The  Lambda  Calcul us 

1.4.1  goals  det ined . 

You  have  Probably  round  reducing  lambda  calculus  expressions 
CO  be  a  tedious  and  error-“Prone  process.  These  characteristics. 
Plus  the  race  that  reduction  is  a  mechanical  procedure,  makes  the 
computer  the  ideal  tool  tor  doing  these  reductions.  There  are 
several  reasons  nor  this,  when  people  work  tor  a  long  ti'^e  at  a 
mechanical  task,  they  become  tired  and  begin  to  make  mistakes. 
Computers  aren't  like  that:  once  programmed  correctly  they  will 
perform  a  cask  without  fatigue.  Another  advantage  of  using  com-“ 
outers  to  do  reductions  is  that  they  can  do  them  so  fast.  The 
mechanical,  symbolic  processes  of  a  calculus  are  exactly  what 
computers  handle  best,  since  a  computer  is  just  a  very  fast  sym¬ 
bol  manipulator. 

Why  are  we  so  concerned  about  reducing  lambda  expressions, 
anyway?  As  you've  seen  in  the  Previous  chapter,  languages  with 
very  different  appearances  are  often  just  "sugared"  versions  of 
the  lambda  calculus.  You've  also  been  told  (and  you  will  see  it 
in  Part  II)  chat  most  common  programming  languages  are,  under¬ 
neath,  just  the  lambda  calculus.  Therefore,  if  you  study  how  to 
implement  the  lambda  calculus,  you  will  be  learning  how  to  imple¬ 
ment  most  of  the  common  programming  languages.  The  advantage  of 
using  the  lambda  calculus,  as  opposed  to  Pascal  or  Ada,  for 
instance,  is  that  the  lambda  calculus  is  so  simple.  The  imple¬ 
mentation  techniques  are  much  easier  to  understand  in  the  clear 
and  uncluttered  context  of  the  lambda  calculus.  Once  understood, 
they  are  easy  to  extend  or  modify  so  that  they  accomodate  the 
complexities  of  "real"  languages. 

1.4.2  mechanical  reduction 

Having  established  that  imolemenation  of  the  lambda  calculus 
is  important,  we  can  proceed  to  study  how  we  might  go  about  it. 
The  obvious  approach  is  to  write  a  program  that  duplicates  our 
hand  reduction  procedures.  This  is  easier  said  than  done,  how¬ 
ever  . 

Let's  investigate  how  we  might  go  about  automating  the 
reduction  process.  When  we  reduce  a  lambda  expression  using  the 
Standard  Reduction  Order,  we  do  it  bv  applying  the  substitution 
rule  over  and  over,  until  we  are  forced  to  stop  by  an  immanent 
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collision  or  variables.  We  then  use  the  renaming  rule  to  change 
the  ottendinq  bound  variable  to  one  that  won't  cause  a  collision, 
and  continue  with  our  substitutions.  ^Ixceot  on  verv  comolex 
lambda  expressions  it  is  generally  easy  to  see  it  there  will  be  a 
collision  of  variables.  This  sort  of  oattern  recognition  orocess 
is  the  sort  of  thing  that  is  very  easy  tor  oeople  and  very  hard 
for  computers.  This  is  because  we  can  see  the  collision  at  a 
glance,  while  the  computer  must  do  the  check  with  an  exhaustive 
search.  That  is,  in  order  to  determine  if  it  is  legal  to  substi¬ 
tute  an  actual  oarameter  for  a  particular  (free)  occurence  of  a 
variable,  it  is  first  necessary  to  comoute  a  list  of  the  free 
variables  in  the  actual  parameter.  Ooing  this  requires  scanning 
Che  expression  and  nocinq  all  the  binding  sites  and  cheir  scones, 
in  is  then  necessary  to  compute  all  the  variables  whose  scopes 
Tantain  the  prospective  substitution  site,  and  co  determine  if 
uny  of  these  variables  are  the  same  as  free  variables  of  the 
actual  parameter.  This  is  a  expensive  check  to  perform  and 
intricate  and  cricky  to  program. 

Another  reason  to  avoid  a  mechanical  implementation  of  the 
reduction  procedure  is  that  it  would  be  slow.  As  you've  probably 
observed  in  your  own  reductions,  this  process  involves  a  lot  of 
recooying  of  the  formulas.  This  is  something  that  most  computers 
don't  do  well.  For  these  reasons  we  will  investigate  an  imple¬ 
mentation  that  involves  neither  textual  substitution  nor  a  com¬ 
plicated  collision-of-var iables  test. 

1.4.3  context 

Let's  take  another  look  at  the  way  people  use  variables. 
Suppose  a  mathematician  reads  a  phrase  such  as,  "Let  9  =  2Hft." 
'•'hat  happens  when  he  later  reads  a  formula  such  as 
"2sin  9  cos  9"?  Does  he  mencally  transform  this  into 

2sin(2-(»fc)  cos(2''»ft) 

by  performming  the  substitutions?  Of  course  not.  Having  been 
told  "Let  9  =  2'ffft",  he  remembers  this  fact  and  associates  9  with 
2'ffft.  We  say  that  he  has  bound  9  to  2nft.  'When  he  reads  the 
formula  "2sin  9  cos  9"  he  interprets  it  contextually,  i.e.,  in 
the  context  of  the  relevant  meanings  of  2,  sin,  cos  and  9,  It  is 
not  necessary  for  him  to  do  a  textual  substitution. 

You  will  remember  that  the  reason  for  the  collision-of- 
variables  restriction  on  the  substitution  rule  was  to  prevent 
altering  the  meaning  of  an  expression  by  changing  the  context  of 
its  interpretation.  In  this  case  the  context  is  just  a  set  of 
bindings ,  i.e.,  associations  between  variables  and  their  values. 
In  the  next  section  you  will  see  how  to  keep  track  of  the  context 
of  a  formula  in  such  a  way  that  it  can  be  evaluated  without  the 
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use  or  substitution,  renaminq  or  collision  tests. 
1.4,4  hand  evaluation 


In  this  section  we  will  study  the  use  or  the  context  or 
environment  of  a  formula  ■*  i.e.,  the  set  ot  bindings  that  oive 
that  formula  its  meaning.  These  will  be  represented  by  diagrams 
of  the  form; 


0 

2i»ft 

2sin 

0  cos  0 

This  expreses  the  fact  that  the  context  of  the  formula 
'  2sin  0  cos  0'  is  the  binding  of  0  to  2l>ft. 

^s  our  first  example,  let's  consider  the  evaluation  of  'x+l' 
in  a  context  in  which  x  is  bound  to  2,  i.e.. 


X  1 

2 

n 

x+l 

Since  this  is  the  context  of  the  entire  formula,  it  is  also  the 
context  in  which  each  of  its  subformulas  must  be  interpreted. 
Hence,  this  can  be  reduced  to 


Now,  the  interpretation  of  x  in  the  context  x=2  is  just  2,  so  we 
have 


2  + 


and  the  interpretation  of  1  in  any  context  is  1,  so 
2+1 


or  3.  Similarly,  we  can  evaluate  x'y  in  the  context  y=3,  x=2. 


3 

Y- 

Lir 

y 

3 

X 

2 

•y 

=  >  X 

X 

g 

. 

X 

y 

JJ 

Next,  we'll  take  a  more  complicated  example,  the  evaluation  of 
'/y { X ■ y } (x+i ) '  in  the  environment  x=2: 


x-y} (x+l) 


'^etore  we  can  bind  y  co  x+1  we  have  to  know  the  value  Dt  x+i  (in 
context,  ot  course).  Mence,  we  will  seoarate  the  two  oarts  ot 
the  apol ica t ion : 


Notice  that  we  have  kept  the  tornula  >y{x*y}  in  context  “  other¬ 
wise  it  would  lose  its  meaning.  Continuing  our  evaluation,  we 
oreviously  saw  that  x+1  in  the  context  x=2  evaluates  to  3,  so  we 
have  : 


What  is  the  effect  of  >y{x‘y}(3)?  It  is  to  add  the  binding  y=3 
to  the  context  of  interpretation; 


We  have  oreviously  seen  that  this  reduces  to 

We  will  expand  on  the  previous  example  a  little.  In  that 
example  we  apolied  to  the  argument  3  the  function  >>y{x‘y}  in  the 
context  x=2,  i.e.,  the  funnction  represented  by 


Mext  we  will  consider  the  evaluation  of  f(3)  in  a  context  that 
binds  f  to  the  above  function.  The  result,  of  course,  should  be 
the  same.  We  start  with 


We  must  evaluate  the  operator  and  operand  seoarately: 


Constants  are  indeoendent  of  the  context,  so  the  operand's  value 
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is  3.  The  ooeracor  is  a  variable,  t,  which  must  be  interpreted 
in  the  context.  When  when  we  substitute  this  detinition  we  qet: 


(3) 

which  we  have  already  seen  is  S .  Motice  that  we  have  always 
oreserved  the  meaning  of  Ay{x‘v}  by  bringing  the  context  along 
with  it.  We  are  now  at  the  point  where  we  can  formally  state  our 
evaluation  rules. 

1.4.5  constants 

Since  the  value  of  a  constant  does  not  deoend  on  its  con¬ 
text,  we  evaluate  it  bv  eliminating  the  context. 


=  >  k 

for  k  a  constant . 

1.4.5  variables 

In  contrast  to  constants,  the  value  of  a  variable  depends 
entirely  on  the  context.  We  find  the  value  of  a  variable  by 
looking  it  uo  in  the  list  of  bindings  in  the  contour  (by  conven¬ 
tion,  we  take  the  first  occurence  of  the  variable  in  that  list). 
The  rule  is: 


=  >  X 


where  v  is  a  variable. 

If  X  is  not  bound  in  this  context,  then  it  is  free  (i.e.,  so  far 
as  we  know  it  has  no  value) . 

1.4.7  abstractions 

An  abstraction  often  will  have  free  variables  that  are 
defined  in  its  context.  If  this  context  is  not  preserved  then 
the  abstraction  will  change  its  meaning.  Therefore,  we  will 
leave  an  abstraction  unevaluated  until  it  is  ready  to  be  applied 
to  some  arguments,  we  show  this  delay  of  evaluation: 


i 
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0  1 

0 

>>x{E} 

=  > 

>vX{E} 

(no  chanqe) 


I.4.S  aoolications 


Consider  an  application  such  as  'f(x+l)'.  Standard  Reduc-* 
tion  Order  says  that  in  order  to  deternine  its  value  it  is  first 
necessary  to  determine  the  value  of  its  operand,  'x+i',  and  its 
operator,  'f'.  Of  course  the  value  of  each  of  these  is  found  by 
interpretinq  it  in  the  context  of  the  entire  application: 


Gj 

1 

C  ( 

^  1 

L  t(e)| 

=  0 

f 

{ 

I  e 

Of  course,  there  is  more  to  the  evaluation  of  applications  than 
this.  If  the  application  is  to  make  sense  then  the  evaluation  of 
the  operator  must  result  in  an  abstraction  (with  its  context) . 
That  is,  we  will  qet  a  result  like; 


AxfO}  i  (A) 


^)ow,  this  means  that  C  is  the  context  of  the  abstraction  /xlE}. 
The  application  above  is  evaluated  by  adding  the  binding  x=A  to 
the  context  C,  and  then  using  this  as  the  context  in  which  to 
interpret  E.  Summarizing,  the  rule  is: 


1— I — 1  1 

I /xfE)  1(A)  => 


T-4,9  Primitive  applications 


We  have  already  seen  several  examples 
primitive  applications,  such  as  'x+1' 
these  it  was  first  necessary  to  evaluate 
primitive.  This  leads  to  the  general  rule 


of  the  evaluation  of'•^ 
and  ' X 'y ’ .  In  each  of 
the  operands  of  the 


n  j 

c 

c 

p (  xi ,  . . . ,  xn) 

=  >  P( 

_ 

xi 

r  •  •  •  t 

xn 

I.4.ih  conditionals 


Recall  that  we  specified  a  deviation  from  Standard  Reduction 
Order  for  conditionals.  We  said  thu  ve  would  first  reduce  the 
condition  and  then,  depending  on  whether  the  result  was  'true'  or 
'false',  reduce  either  the  true  branch  or  the  false  branch.  This 
avoids  errors  in  situations  where  the  other  branch  is  not 
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reducible.  Reducing  the  condition  is  accomplished  bv  the  rule: 


=  > 


When  the  condition  has  evaluated  to  'true'  or  'raise'  the  follow¬ 
ing  rules  interpret  in  context  the  corresponding  branch. 


=  > 


=  > 

1.4.11  example  of  hand  evaluation 

^s  an  example  of  these  procedures  we  will  evaluate 
let  i=3  in 

let  f  =  proc(x)f  x*i  }  in 
let  i=2  in 
f  (i) 

which  we  saw  in  Chapter  3.  The  crucial  aspect  of  this  example  is 
chat  the  context  of  orQC{x){x'i}  is  i=3.  We  can  see  that  this 
context  is  preserved  in  the  following  figure.  In  this  example  we 
first  eliminate  syntactic  sugar  and  write  the  above  formula: 

>i{  >f{  >i{  f(i)  }(2)  >{>x{x-i}  )  }(3) 

1.4.12  representation  defined 

We  will  next  write  an  interpreter  for  ELC  (the  extended 
lambda  calculus)  in  ELC.  Since  we  will  be  using  ELC,  and  the 
only  primitives  we  have  in  ELC  are  for  manipulating  lists,  we 
will  have  to  encode  lambda  expressions  as  lists  so  that  thev  can 
be  manipulated.  This  is  the  representation  we  will  use: 


EORM  EXAMPLE  REPRESEMTATIOM 

constants  2  <'const'  2> 

'string'  <'const'  'string'> 

<5  8  iS>  <'const'  <5  B  18>> 

variables  x  <'var'  'x'> 

abstractions  >xy{E}  <'lambda'  <'x'  'y’>  E> 

applications  F(A,B)  <'cali'  E  <A  B>> 

prim,  applies.  cons(A,B)  <’prim'  'cons'  <A  B>> 

conditionals  T  c  — >  t  I  t  ]  <'if'  c  t  f> 


^i^ure  1.  '^xa'npie  of  Hand  Hvaluacion 

It:  is  necessary  to  append  the  "tag  word"  'const'  to  the  beqinninq 
of  constants  to  prevent  contusion,  for  instance,  between  the 
lists  representing  variables  and  constant  lists  that  haooen  to 
begin  with  the  string  'var'- 


We  will  look  at  several  examples  of  lists  that  represent 
lambda  expressions.  The  expression 
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t(l.2) 


is  reoresente^  bv  the  list: 

<'call'  <'var'  '  t const  ‘  1>  <'const'  2'>>  > 
The  ori.nitive  apolicetion 


cons  (y ,  <■>  1 


is  represented  hv 

<'orim‘  'cons'  «'var'  * v ‘ >  <‘const'  <>>  » 

For  a  more  complicated  example,  consider: 

>xy(  cons  {  x,  cons  (  y,  <>  ))  f 

This  is  reoresented  hv 

<'lambda’  <'x’  'y'> 

<'prim'  'cons'  «'var'  ' x ’ > 

<'Drim’  ' cons '  <<  ' va r '  v’> 

<' const'  <>>  >>>» 


1.4.13  t ield  accessing  tunctions 

Suooose  L  is  a  list  representing  an  abstraction,  e.p., 
<'lambda'  <'x'  'y'^  <'var'  'x'>'> 

It  we  wish  to  extract  the  hound  variables  trom  L,  we  can  do  this 
by  L  r  2 1 : 

Lr21  =>  <'x'  'y'> 

Similarly,  the  body  ot  the  abstraction  can  be  extracted  bv  LHl: 

Lr31  =>  <'var'  'x'> 

Both  ot  these  ooerations  will  be  more  readable  it  we  detine  the 
t i e  1  d  accessing  tunctions  '’bvs'  and  "body'  to  get  the  bound  vari¬ 
ables  and  body,  resoectively ,  of  an  abstraction; 

let  bvs  *  r)roc(x){  xr21  1 

and  body  =  !oroc{x)f  xf31  }  in  ... 


Then  we  can  write 


Hvs  (L)  =">  <  '  y'  ■'/■> 

ho'^yfL'  =>  <'var'  ’  x ' 

It  will  also  “oe  osetul  to  have  a  tunction  'is-la’ih^a'  to  tell  as 
it  a  list  reoresents  an  ahsr faction: 

let  is-lanhda  =  oroc(y)f  x f 11  =  'lanh^a'  1  in  ... 

This  t'unccion  detefaines  it  a  list  reoresents  an  abstraction  hv 
checkinq  it  its  'taq  word"  is  'la-nhda'.  ='or  instance, 

is-*lanhd3  (LI  =■>  true 
i s-lanhda (  <'con3t’  2>  )  =>  talse 

Ot  course,  we  will  want  functions  like  'hodv'  and  'is-lanhda'  tor 
each  ot  the  lists  which  reoresent  a  ty^e  ot  lanhda  exnression. 
'father  than  detine  each  seoarately  like  we  did  above,  we  will  use 
the  abbreviation 

structure  lambda:  (bvs,  body) 

to  mean  that  lists  whose  tirst  element  is  'lambda'  will  have  two 
more  elements,  selected  by  the  tunctions  'bvs'  and  ’body'.  This 
is  called  a  structure  definition  and  is  equivalent  to  the 
declaration: 

let  is-lambda  =  oroc(x){  x r l 1 =' lambda '  } 
and  bvs  =  oroc(x)f  xC^T  } 
and  body  =  orocfxlf  xfll  } 

in  ... 

The  structure  declarations  for  the  lists  that  reoresent  lambda 
exoressions  are  qiven  in  the  followinq  fiqure.  The  definition  ot 
these  field  accessinq  tunctions  will  make  our  interoreter  much 
more  readable. 

structure  const:  (constval) 
structure  var:  (id) 
structure  lambda:  (bvs,  body) 
structure  call:  (rator,  rands) 
structure  orim:  (rator,  rands) 
structure  it:  (cond,  t-branch,  f-branch) 

^'iqure  2.  Lists  henresentinq  Lambda  'Exoressions 

1.4.14  association  lists . 

So  that  environments  (contexts)  can  be  manipulated  bv  the 
orimitives  with  which  we  have  equiooed  the  lambda  calculus,  we 
will  define  a  reoresentation ,  called  an  association  list  (or  a- 
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list>  .  tor  envirtinments.  a.rv  association  list  is  just  a  list 
wherein  each  element  ot  the  list  is  a  pair  containing  the  name  ot 
a  variable  and  its  value.  ““or  instance,  an  association  list 
reoresenting  an  environment  in  which  x=2,  y* ' '^onterev ’  and  2*<0  1 
2  V  is; 

<  <’x’  22  <'y’  ’Monterev'2  <’z'  <0  1  22>  > 

'•/e  will  detine  several  orimicive  tunctions  on  association  lists. 
The  tunction  'assoc'  is  defined  so  that  ' assoc ^ x , a> '  is  the 
result  of  loo'<inq  uo  that  variable  name  x  in  the  association  list 
a . 

let  rec  assoc  =  ococ<x,a)  begin 

if  equal  (  x,  af.  llfll)  then  aril  f  21 
else  assoc(  x,  restial)  endit  end. 

'^or  instance,  it  L  is  the  a-list 

<  <'x’  2>  <'v‘  ’'^onterev'o  <'2’  <h  1  2'>>  2 


then 


assoc(  'y',  t.1  =>  'Monterey', 

The  function  'oairlis'  i.s  a  little  more  complicated;  it  is  used 
for  binding  variables  to  valvies  and  ^dairio  them  to  ’o^-^ci^tion 
list.  That  is.  if  x  is  a  list  oc  v»r:a-le  n^-ios .  v  is  a  list  ot 
values  and  a  is  an  association  list,  then  ' oa i r 1  is { x . v , a) '  is  an 
association  list  in  which  each  element  ot  x  is  naired  with  the 
corresnonding  element  of  y  and  aooended  to  the  front  of  a.  '='or 
instance, 

pairlis(  <‘w'  'cost'>,  252,  L  ) 

=  2  <<'w'  52  <’cost'  252  <’x'  2>  <'y'  "^onterey'2  <'2'  I  22>>. 

To  see  how  this  can  be  done,  notice  that  if  'a'  is  an  a-list,  and 
<xi  yi>  is  a  oair  reoresenting  a  binding,  then 

cons(  <xi  vi>, 

will  add  this  oair  to  'a'.  The  resultino  definition  of  'oairlis' 
is: 

let  rec  oairlis  =  oroc(x,y.a)  begin 
it  null(x1  then  a 
else  cons(  oairf  xlH  ,  yfil  ), 

pairlisi  rest(x),  rest(y),  a)  )  endif  end 
where  oair  *  proc(x,y){  cons (  x.  cons (  y ,  <2  ) )  1. 


I  .  4 . i S  closures 

We  have  oreviously  seen  that  it  is  necessary  to  keen  an 
abstraction ' s  context  with  that  abstraction  in  order  to  preserve 
its  meaning.  We  have  symbolized  this  with  diagrams  like: 

' - tti - 

I  X  i  3  I 

I  >>y{x+y} 

We  will  now  investigate  in  more  detail  the  nature  ot  this  con¬ 
struct  . 

\  formula  is  called  closed  if  it  has  no  free  variables,  for 
instance , 

>x(  >,y{x+y}  }  (3) 

Closed  formulas  are  imoortant  because  their  internr etation  is 
completely  independent  of  context.  A  formula  is  called  open  if 
it  has  one  or  more  free  /atli’oles.  Hence,  open  formulas  are 
dependent  on  their  context  for  their  interpretation.  This  for¬ 
mula  is  open: 

>y{ x+y} 

An  open  formula  can  be  closed  by  providing  bindings  for  its  free 
variables.  For  instance,  the  above  open  formula  can  be  closed  by 
binding  x  to  3; 

let  x=3  in  >.y  (  x+y } 
o  r 


><<  {  Ay  {x+y}  }  (3) 


This  is  called  the  closure  of  the  formula  >y{x+y}.  More  gen¬ 
erally,  a  closure  is  a  formula  together  with  bindinos  for  all  of 
its  free  variables.  This  is  just  the  construct  we  have  illus¬ 
trated  by 


X  1  .3 

V 

•< 

x+y } 

Our  next  task  will  be  to  determine  how  we  can  implement  closures 
using  lists.  The  key  is  our  diagram;  a  closure  has  two  parts: 
an  abstraction  and  its  context.  These  parts  are  traditionally 
called  the  ^  and  ep,  which  stand  for  instruction  part  and 
envi ronment  part ,  respectively.  We  will  represent  a  closure  by  a 
structure  with  two  fields  called  'ip'  and  'ep'.  The  ip  will  be  a 
list  that  represents  an  abstraction  and  the  ep  will  he  an  a-list 
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r epr esentinq  a  context.  This  is  summarized  by 

structure  closure:  (in,  eo) 

The  function  tor  constructinq  closures  is  defined: 

let  closure  =  proc(ip,ep){ 

cons (  'closure',  oairf  iv.  eo  ))  } 

Thus,  we  can  make  a  closure  from  the  abstraction  f  and  the 
environment  e  by  closur e  {  f  ,  e) : 

closure(f,e)  =>  <'closure'  f  e> 


We  can  test  if  somethinq  is  a  closure  bv  i s-closure  (c)  and 
extract  its  oarts  by  iD{c)  and  ep(c).  The  closure  data  type  is 
described  in  the  followinq  fiqure. 


io(  closure(f,e)  )  =  f 

ep(  ciosure(f,e)  )  =  e 

closure(  ip(c),  en(c)  )  = 

c 

is-closure(  closure(f,e)  ) 

=  true 

where  is'-lambda  ( f ) 

and  e  is  an  a-list 

and  is-closure ^c) 

Piqure  3.  The  Closure  Data 

Type 

I.A.lPi  mechanical  evaluation . 


We  will  define  a  function  'eval'  such  that  if  'e'  is  a  list 
representinq  a  lambda  expression  and  'a'  is  an  association  list 
representinq  an  environment,  then  'eval(e,a)'  is  the  result  of 
evaluatinq  that  lambda  expression  in  that  environment.  Thus, 
'eval(e,a)'  corresponds  to 


a_J 

e 


The  structure  of  our  interpreter  will  be  a  larqe  conditional  so 
that  we  can  handle  lambda  expressions  case  by  case.  In  skeleton 
form  it  is; 
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let  rec  '^val  =  Droc(e,a) 
beq  in 

in  is-const(e)  then  ... 

elsit  is**var(e)  then  ... 

elsir  is-lambda  (e)  then  ... 

elsin  is-callfe)  then  ... 

elsit  is-Drin(e)  then  ... 

elsit  is-if(el  then  ... 

end  i  r 
end 
in  ... 

We  will  consider  each  ot  these  cases  in  turn.  In  discussing 

them,  it  will  be  helotul  it  vou  refer  back  to  the  field  names 
defined  in  figure  2, 

The  simolest  case,  as  we  have  already  seen,  is  constants, 

because  they  do  not  deoend  on  the  context  for  their  interoreta- 

tion.  In  this  case  we  just  extract  the  constant  value  from  the 
list  and  return  it: 

if  is-CQnst(e)  then  const-*val  (e) 

The  next  simpler  case  is  variables.  The  result  of  evaluating 

<'var'  x>  is  just  the  result  of  looking  up  x  in  the  current 
environment  (which  is  the  a-list  bound  to  'a'); 

elsit  is-var{e)  then  assoc(  id(e),  a) 

^s  discussed  in  the  orevious  sections,  the  rule  for  abstractions 
will  form  a  closure  by  combining  the  abstraction  and  its  environ¬ 
ment  of  definition  (context).  This  is  accomolished  bv; 

elsit  is-lambda(e)  then  closure(e,a) 

When  this  closure  is  apnlied  to  its  ooerands  by  a  aoolication , 
the  'apply'  function  will  extract  the  environment  of  definition 
(ep)  from  the  closure  and  use  it  as  the  basis  for  constructing 
the  environment  of  evaluation  for  the  bodv  of  the  abstraction 
(ip)  . 

•'lext  we  will  consider  the  case  of  Primitive  applications. 
If  e  is  a  Primitive  application  then  rator(e)  is  its  operator, 
which  is  a  string  such  as  'tirst'  or  'cons',  and  rands(e)  is  a 
list  of  its  ooerands.  In  our  hand  evaluation  Procedure,  we  first 
interpreted  the  operands  in  context  and  then  performed  the  primi¬ 
tive  operation.  Here  we  will  use  an  auxilliary  cunction  'evlis' 
to  evaluate  the  operands  and  an  auxilliary  function  'apoly-orim' 
to  perform  the  operation: 
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elsit  is-Drim(e)  then  apDlv-Drim(  rator(e),  actuals) 
where  actuals  =  evlis{  rands(e),  a) 


Flvlis  is  a  simple  recursive  procedure  that  evaluates  each  element 
or  its  argument  list  and  returns  a  list  of  the  results: 


let  rec  evlis  =  nrQc(L,a)  begin 
if  null(L)  then  <> 

else  cons {  eval  (  Lfil,  a),  evlis(  rest(L),  a))  endif  end 


The  definition  of  ' apoly-pr im ’  is  simply  a  conditional  for  han- 
dling  each  of  the  primitive  onerations: 


j.et  apoly-^prim  = 
if  f=' first' 
elsif  f='rest' 
elsif  f=’cQns' 
elsif  f='atom' 
elsif  f='null' 
endi f  end  in  . . 


proc(t,x)  begin 
then  f ir St (x r n ) 
then  rest (xfll ) 
then  cons  (  x [1 ]  , 
then  atom (x ri] ) 
then  null (xCil ) 


^[2}) 


Of  course,  if  we  want  additional  primitive  operations,  we  can 
just  add  clauses  for  handling  them  to  the  definition  of  'aoplv- 
prim’  . 


The  aoolication  of  non-^or imitve  operations  is  a  similar  oro- 
cess.  The  operands  must  be  evaluated  using  'evlis',  as  was  done 
for  primitive  apolicati ons.  Since  the  operator  is  also  a  for¬ 
mula,  it  also  must  be  evaluated  in  context.  This  evaluation  must 
yield  a  closure.  The  closure  is  then  applied  to  the  actual 
parameters.  That  is: 

elsif  is-call(e)  then  apply(  closure,  actuals) 
where  closure  =  eval(  rator(e),  a) 
and  actuals  =  evlis(  rands(e),  a) 

Next,  we  must  consider  what  'apply'  has  to  do  to  comolete  the 
function  call.  In  our  hand  evaluation  orocedure  we  paired  the 
bound  variables  with  the  corresponding  actual  parameters  and 
added  these  bindings  to  the  context  of  the  abstraction.  This  new 
context  was  use*  as  the  environment  for  evaluating  the  body  of 
the  abstraction.  We  will  do  the  same  here. 

If  b  is  the  list  of  bound  variables,  x  3  the  list  of  actual 
oarameters  and  c  is  the  context  of  the  abstraction,  then 
pairlis (b,x,c)  is  the  environment  in  which  to  evaluate  the  body 
of  the  abstraction.  The  'acplv'  function  that  accomplishes  this 
is : 
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let  rec  apoly  =  proc{  closure,  actuals)  beqin 
let  abs  =  iD(closure)  in 

let  env  =  pairlis(  bvs(abs),  actuals,  ep(closure)  )  in 
eval(  body(abs),  env  )  end 

The  only  case  left  to  be  analyzed  is  the  conditional.  In  our 
hand  evaluation  orocedure  we  interpreted  the  condition  in  context 
to  get  a  truth  value.  We  then  used  this  value  to  determine 
whether  to  evaluate  the  true  branch  or  the  false  branch  of  the 
conditional.  This  is  exactly  what  needs  to  be  done  in  'eval': 

elsif  is-if(e)  then 
if  eval  (  cond  (e)  ,  a) 

then  eval(  t-branch(e),  a) 

else  eval  (  f'*branch  (e)  ,  a)  endif 

This  completes  the  definition  of  'eval';  the  complete  interoreter 
is  shown  in  the  following  figure. 


let  rec  Eval  =  proc(e,a)  begin 

if  is-*const(e)  then  const-val(e) 
elsif  is-var(e)  then  assoc(  idfe),  a) 
elsif  is-lambda(e)  then  closure(  e,  a) 
elsif  is-prim(e)  then  aDply-prim(  rator(e),  actuals) 
where  actuals  =  evlis(  rands(e),  a) 
elsif  is-call(e)  then  apply{  closure,  actuals) 
where  closure  =  eval(  rator(e),  a) 
and  actuals  =  evlis(  rands(e),  a) 
elsif  is-if(e)  then 

if  eval{  cond{e),  a)  then  eval(  t-branch(e),  a) 
else  eval  (  f-branch  (e) ,  a)  endif 
endif  end 

and  rec  evlis  =  proc(L,a)  begin 
if  null  (L)  then  <> 

else  cons(  eval(L[n,a),  evli  s  (  rest  (L)  ,  a  )  )  endif  end 

and  rec  aoDly  =  oroc(  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  pairlis(  bvs(abs),  actuals,  eoCclosure))  in 
eval (  body(abs),  env)  end 

and  apply-prim  =  proc(f,x)  beqin 
if  f®'first'  then  firstCxQ)) 
elsif  f='cons'  then  consf  xfil ,  xr21  ) 
els i f  ... 
endif  end 

X  n  «  •  a 

Figure  4.  a^-List  Eval 
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The  interoreter  is  very  similar  to  the  interpreters  used  for  LISP 
and  similar  lanquaqes.  To  clarify  its  operation,  several  exam¬ 
ples  will  be  presented.  In  these  examples  we  will  trace  the 
invocations  of  'eval'  and  'apply'  and  occasionally  ocher  func¬ 
tions. 


EXAMPLE  i:  reduction  of  Xxy{ cons (y , x ) } ( <2  3>,  i). 

In  the  list  representation  this  is: 

E  =  < ' call '  F  A> 

F  =  <'iambda'  <'x'  'y'>  3> 

3  =  t'prim'  'cons'  P> 

P  =  <<'var'  'y'>  <'var'  'x'>> 

A  =  <<'consc'  <2  3>>  <'const'  i>> 

Evai (E ,  <>) : 

closure  =  eval(F,<>)  =  t'closuce'  F  <>> 
actuals  =  evlis(A,<>)  =  <<2  3>  i> 
appiy(  closure,  actuals  ): 
abs  =  F 

env  =  pairlisC  <'x'  'y'>,  actuals,  <>  ) 

=  <<'x'  <2  3>>  <'y'  i>> 
aval (3 ,env) : 

actuals  =  evlis(  <<'var'  'y'>  <'var'  'x'>>,  env  ) 

=  <1  <2  3>> 

iyply-prim(  'cons',  <1  <2  3>>  ); 
cons(  1,  <2  3>  )  =  <i  2  3> 

EXAMPLE  2:  Reduce 

let  i  =  3  in 

let  f  =  /x{  prod(x,i)  }  in 
let  i  =  2  in 
f  (i) 

To  translate  this  to  list  representation  it  is  necessary  to  first 
eliminate  syntactic  sugar: 

>,i{  Af  {  >i{  f(i)  }{2)}(  >x{prod  (x  ,  i)  )  )}(3). 

Notice  that  by  doing  a  hand  reduction  of  this  we  can  determine 
that  the  correct  reduction  is  5.  For  the  sake  of  this  example  we 
will  assume  chat  'eval'  can  evaluate  the  primitive  application 
'prod',  which  multiplies  two  numbers. 
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2  =  <'cai:'  I  <<'ccnst:'  3>>  > 

I  =  <’ lambda'  <'i'>  <'caii'  F  <:<>>  > 

F  =  <'lambda'  <'t'>  <'cali'  J  <<'const.'  2>>  >> 

J  =  <'lambda'  <'i'>  <'caii*  <'var'  'i'>  <<’var'  'i'>>  >> 

X  =  <’ lambda'  <'x'>  P> 

P  =  X'ptiiti'  'ptod'  <<'var'  'x'>  <'vat'  'i'>>  > 

2val (  2  ,  <>  )  : 
c^osuie  =  <'c^c,sute'  I  <>> 
actuals  =  <3> 

appx/(  cltsuie,  actuals  ): 
abs  =  I 

env  =  <<  '  j.  '  3>> 

evai(  <'cali'  F  <X>>,  <<'i'  3>>  ); 
closure  =  <'closute'  F  <<'i'  3>>  > 
actuals  =  3v^i3(  <X>,  <<'i'  3>>  ) 

=  <C>  where  C  =  <'closure'  X  <<'i'  3>>  > 
appiy(  closure,  actuals  ): 
abs  =  X 

env  =  <<  '  L  '  C>  < '  i  '  3>> 
evai(  X'cail'  J  <<'const'  2>>>,  env  ): 
closure  =  X'closure'  J  <<'t'  C>  <'r'  3>>  > 
actual s  =  <2> 

apply(  closure,  actuals  ): 
abs  =  J 

env  =  << ' r  2>  <' t'  C>  < ' r '  3>> 

eval  (  <'ca**'  <'var'  'l'>  <<'var'  'i'>>  >,  env  ): 
closure  =  eval (  <'var'  'i'>,  env  )  =  C 
actual.3  =  <2> 
apply(  closure,  actuals): 
abs  =  X 

env  =  paicli3(  <'x'>,  <2>,  ep(clo3uie)  ) 

=  pairlisC  <'x'>,  <2>,  <<'i'  3>>  ) 

=  << ' X '  2>  <  '  1 '  3>> 
aval (  P ,  env  ) : 

actuals  =  eval(  <<'var'  'x'>  <'vat'  'i'>>,  env  ) 

=  <2  3> 

p£im-apply{  'prod',  <2  3>  ): 
prod  (2,3)  =  5 

Do  the  reduction  by  hand  to  be  sure  you  see  that  this  is  the 
riqht  answer. 

T.4,17  replacement  of  variables  by  fixed  locations .  Observe 
that  our  current  interpreter  spends  a  lot  of  its  time  searching 
association  lists  for  the  values  of  variables.  That  is,  the 
evaluation  of  <'var'  'x'>  in  the  environment  'a'  requires  search¬ 
ing  'a'  for  a  pair  whose  first  element  is  'x'.  Such  searching  is 
expensive  on  most  comouters,  so  we  will  develop  a  method  of 
interpreting  the  lambda  calculus  which  does  not  require  it.  In 
oarticular,  we  will  replace  searching  by  array  subscripting, 
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which  is  much  more  efticienc.  '»'e  will  develop  the  orocess  tor 
single  variable  abstractions  initially  and  later  extend  it  tor 
multiple  variables.  Consider  an  abstraction  'Ax^El'  in  some 
environment  The  closure  formed  from  evaluating  this 
abstraction  will  be 


<'closure’  <'lambda'  <'x’>  <...>  >. 


When  this  closure  is  applied  to  an  ooerand  value  'u'  its  evalua¬ 
tion  will  always  take  the  form 

eval (  E,  <<'x'  u>  ...>  ). 


Motice  that  the  bound  variable  of  the  abstraction  being  evaluated 
will  always  occupy  the  first  pair  of  the  environment.  Therefore 
there  is  really  no  reason  to  search  for  this  variable  since  we 
know  where  it  is.  Since  the  abstraction  we  chose  was  arbitrary, 
this  can  be  seen  to  be  true  for  all  abstractions.  In  fact,  we 
find  that  it  is  true  for  all  variables  that  we  can  determine  the 
position  of  each  variable  in  the  environment  by  counting  the 
number  of  "scoping  lines"  that  must  be  crossed  in  getting  from  a 
use  of  the  variable  to  its  definition.  This  number  is  called  the 
static  distance  of  a  variable  from  its  definition,  and  is  for¬ 
mally  defined  to  be  the  number  of  scopes  containing  the  use  of 
the  variable  that  do  not  contain  its  definition  (binding 
occurence).  For  instance,  in 
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the  static  distances  of  the  variables  from  their  definitions  are 
indicated.  For  'f  it  is  2,  for  'x'  it  is  1,  for  the  leftmost 
'i'  it  is  i  and  for  the  rightmost  'i'  it  is  2.  Since  we  know 
where  each  variable  occurs  in  the  association  list,  we  can 
replace  expressions  of  the  form  <'var'  'x'>  with  expressions  of 
the  form  <'var'  n>  where  n  is  the  position  of  variable  'x'  in  the 
environment.  This  value  n  will  be  called  the  or  variable 
position ,  as  indicated  in  the  new  structure  declaration  for  vari¬ 
ables: 


structure  var:  (vo) 

Since  we  no  longer  use  the  variable  names  to  look  them  up  in  the 
environment,  we  can  eliminate  them  and  represent  the  environment 
as  a  list  of  values  rather  than  an  association  list.  For 
instance  the  association  list 

<  <'x'  2>  <'y'  'Monterey'o  <'z'  <0  i  2>>  > 


r 
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will  be  simolified  to 

<  2  'Monterey'  <0  1  2>  >. 

Then,  looking  up  <'var'  n>  in  environment  'a'  is  simply  accom-“ 
plished  by  afnl.  Since  variables  are  no  longer  needed,  the  bound 
variable  list  can  also  be  eliminated  from  the  reoresentati on  of 
abstractions.  For  instance  '>x { cons (x , <> ) } ’  is  represented  bv 

<'lambda'  <’prim’  'cons'  <'var'  i>  <'const'  <>  >>  >. 

The  new  structure  definition  for  abstractions  is: 

structure  lambda:  (body) 

This  process  of  converting  variables  from  names  to  numeric  loca¬ 
tions  is  one  that  is  usually  oerformed  by  a  translator  or  com¬ 
piler.  Since  we  are  translating  bv  hand  from  the  lambda  calculus 
to  its  list  representation,  we  must  do  this  counting  ourselves. 
It  is  generally  true  of  nrogramming  language  implementations 
that,  as  we  have  done  here,  t)ie  run-time  efficiency  of  a  program 
can  be  increased  by  doing  more  work  at  comoile  time. 

There  are  only  a  few  simple  changes  necessary  to  convert 
'eval'  to  use  the  new  numeric  variables  --  all  simol i f ications . 
The  rule  for  'var's  is  simply  altered  to  subscriot  the  requred 
value  out  of  the  environment: 

elsif  is-var  then  aTvpCe)! 

The  only  other  change  is  to  the  'apply'  orocedure:  since  environ¬ 
ments  are  simple  lists  of  values  the  environment  of  evaluation  is 
constructed  by  apoending  the  operand  to  the  front  of  the  environ¬ 
ment  of  definition. 

and  rec  apply  =  proc(  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  append (  actuals,  ep(closure)  )  in 
eval(  body (abs),  env)  end 

To  clarify  these  ideas  we  will  trace  the  evaluation  of  the  lambda 
expression: 

>i{  >,ff  >i{  f{i)  1(2)  }(  >x{prod  (i  ,x)  }  )  }(3) 

This  is  represented  by  the  list: 
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E 

I 

F 

J 

X 

P 


< ' call '  1 
< ' lambda ' 
<' lambda ' 
< '  lambda ' 
< '  lambda ' 
< ' pt im '  * 


<<'cGnst.'  3>>  > 

<'cai:.’  F  <X>>  > 

<'caii'  J  <<'const.'  2>>  >> 
<'call'  <'vat'  2>  <<'var'  j.>> 
P> 

plod*  <<'var'  2>  <'var'  i>>  > 


>> 


Svai {  S ,  <>  )  ; 

apply(  <'ciosuie'  1  <>>,  <3>  ): 
env  =  append(  <3>,  <>  )  =  <3> 
evaj.  (  <'call'  F  <X>>,  <3>  ): 

Evaluation  proceeds  much  as  beroie,  until  the  stage  when  the 
application  t(i)  must  be  evaluated: 

evai(  <'caii'  <’var'  2>  <<'var'  i>>  >,  <2  C  3>  ): 
closure  =  evai{  <'var'  2>,  <2  C  3>  )  =  C 

actuals  =  evli3(  <<'var'  i>>,  <2  C  3>  )  =  <2> 
apply (  C ,  <2>  ) ; 

env  =  append{  <2> ,  <3>  )  =  <2  3> 
eval (  P,  <2  3>  )  : 

actuals  =  evlis(  <<'var'  2>  <'var'  1>>,  <2  3>  ) 

=  <3  2> 

ptim-apply(  'prod',  <3  2>  )  =5 


1.4.18  static  nesting  level .  The  approach  used  above  is  based 
on  the  replacement  by  the  translator  ot  variable  names  by  numbers 
indicating  the  static  distance  ot  the  use  of  the  variable  from 
its  definition.  This  number  will  vary  from  one  use  of  a  variable 
to  another.  For  instance,  in 

/x{  cons(  X,  >y{  cons(  x,  append(Y,y)  )  }(<A  3>)  )  } (C) 

the  first  use  of  'x'  will  be  translated  by  <'var'  1>  while  the 
second  use  of  'x'  will  be  translated  by  <'var'  2>.  The  transla-* 
tion  process  would  be  a  little  simpler  if  a  single  number  was 
always  associated  with  all  uses  of  a  given  variable.  We  can  do 
this  by  using  the  static  nesting  level  of  the  definition  of  the 
variable  as  this  number.  The  static  nesting  level  of  the 
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definition  of  a  variable  is  one  more  than  the  number  or  scooes  in 
which  that  definition  of  the  variable  is  nested.  In  the  diagram 
below,  the  static  nesting  levels  of  the  variables  are  indicated: 


The  above  diagram  also  indicates  the  static  nesting  level  of  the 
uses  of  variables.  Notice  that  the  static  nesting  level  of  the 
use  of  a  variable  is  the  sum  of  the  static  nesting  level  of  its 
definition  and  the  static  distance  to  that  use.  Therefore  we  can 
calculate  the  static  distance  from  the  static  nesting  level  or 
vice  versa.  This  means  that  one  way  to  alter  'eval'  to  use 
static  nesting  levels  is  to  alter  it  to  compute  the  static  dis¬ 
tance  and  then  to  extract  the  value  from  the  environment  in  the 
orevious  way.  There  is  a  simoler  way,  however,  since  we  can  so 
construct  the  environment  that  the  static  nesting  level  can  be 
used  to  directly  access  the  environment.  To  understand  the  way 
this  is  done  notice  that  with  our  present  'eval'  the  "innermost" 
variable  is  first  in  the  environment  and  the  "outermost"  variable 
is  last  in  the  environment.  To  make  most  convenient  use  of 
static  nesting  levels  we  want  to  construct  the  environment  so 
that  the  "outermost"  variable  (i.e.  that  at  static  nesting  level 
1)  is  the  first  (i.e.  atn)  and  the  "innermost"  is  last.  This  is 
accomplished  by  simply  concatenating  the  latest  variable  values 
to  the  right  of  the  environment  rather  than  the  left.  The  only 
required  alteration  to  the  interpreter  is  to  switch  'actuals', 
and  ' ep(cIo3uca) '  in  apply: 

let  rec  aooly  =  proc (  closure,  actuals)  begin 
let  abs  =  iD(closure)  in 

let  env  =  aooend  (  ep(closure^,  actuals  )  in 
eval (  body(abs),  env)  end 

The  translation  of  lambda  expressions  into  the  list  representa¬ 
tion  is  simplified  since  a  variable  is  always  translated  in  the 
same  way.  The  translation  of  our  previous  example  is: 

J  =  <'iambda'  <'caii'  <'var'  2>  <<'var'  3>>  >> 

P  <'piim'  'prod'  <<'var'  i>  <'vac'  2>>  > 

E.XSRCISS ;  Trace  the  evaluation  or.  this  list. 
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I. -1.19  multiple  parameters .  To  keep  the  discussion  simple,  we 
have  only  been  discussinq  the  implementation  of  abstractions  and 
applications  with  a  single  parameter.  We  will  now  extend  our 
implementation  to  handle  more  than  one  parameter. 

In  our  current  implementation  (using  static  nesting  levels) 
the  environment  is  represented  by  a  list  of  the  form 


<Vi  Vj 


where  v-  is  the  value  of  the  variable  bound  at  static  nesting 
level  1.  To  handle  multiple  parameters  we  will  simply  replace 
each  of  these  values  with  a  list  of  the  values  bound  at  each 
static  nesting  level.  That  is,  an  environment  has  the  form 


<ar2  arp 


ar  > 
n 


where  each  ar,-  is  called  the  activation  record  (or  call  frame ) 
for  static  nesting  level  i.  An  activation  record  is  defined  to 
be  all  .JL  the  information  relevant  to  a  call  of  a  function.  'lach 
activation  record  has  the  form 

<v-.  V,  ...  v„> 

X  m 

where  the  v,-s  are  the  values  of  the  variables  declared  at  the 
static  nesting  level  corresponding  to  the  activation  record.  To 
access  a  variable  it  is  now  necessary  to  use  two  coordinates, 
(ep,vp)  ,  where  the  environment  part  (^)  is  the  static  nesting 
level  of  the  activation  record  containing  the  variable,  and  the 
var iable  part  ( vp)  is  the  position  of  the  value  of  the  variable 
within  that  activation  record.  For  example,  if  we  are  in  the 
environment 


<  <1  2  3>  <'A' 


'C'>  <4  'D'  <5  'P’>  > 


then  the  (eo,vp)  pair  (2,1)  will  refer  to  'A',  the  pair  (3,2) 
will  refer  to  '0'  and  the  pair  (3,3)  will  refer  to  <5  6>.  In 
particular,  if  'a'  is  the  environment,  then  'a[epl[vpl'  is  the 
value  of  the  variable  corresponding  to  the  pair  (eo,vp) .  In 
order  to  make  use  of  this  new  structure  for  the  environment,  it 
is  necessary  to  translate  variables  into  lists  of  the  form 

< ' var '  ep  vp> 

where  (ep,vp)  is  the  location  of  the  variable.  This  corresponds 
to  the  structure: 


structure  var:  (ep,  vp) 


Therefore,  to  handle  multiple  parameters,  the  rule  for  'var's 
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'eval'  must  be  changed  ta; 

elsit  is-var(e)  then  arrvD(e)1 
where  ar  =  a  Tep  (e) 1 

The  next  issue  to  be  addressed  is  the  construction  of  these 
environments  by  the  'apoly'  procedure.  If  the  environment  of 
definition  from  the  closure  is 


<afi 


and  the  actual  oarameters  of  the  apolication  are 


<v-  V-  . . 

j.  z 


m 


then  the  environment  in  which  the  body  of  the  abstraction 
evaluated  should  be 


<ari 


ar„  <v-  V, 
n  j.  2 


That  is,  a  new  activation  record,  ’’’  '^m'* '  made  the 

new  last  element  in  the  environment.  If  "^ep'  is  the  environment 
of  definition  and  'x'  is  the  actual  oarameter  list,  then 

consR(  ep,  x  ) 

where  consR  =  proc(L,x){  append (  L,  cons(x,<>)  )  } 

will  construct  the  environment  of  evaluation.  The  aobropr iately 
modified  'apply'  is: 

let  rec  aooly  =  proc (  closure,  actuals)  begin 
let  abs  =  ip{closure)  in 

let  env  =  consR(  ep(closure),  actuals)  in 
eval(  body (abs),  env  )  end 

and  consR  =  oroc(L,x){  append (  L,  cons(x,<>)  )  } 

The  complete  'eval'  is  shown  in  the  next  figure.  To  demonstrate 
the  operation  of  the  new  'eval',  we  will  trace  the  reduction  of 

>xy{  Xzi  z*z  +  X  }  (x+y)  }  (2,3) 

First  we  translate  the  lambda  expression  into  our  list  represen¬ 
tation,  numbering  the  lambdas  as  before: 

<call  <lambda ( 1 ) 

<call  <lambda(2)  <prim  sum  <prim  prod  <var  2  1>  <var  2  i>> 

<var  1  1>>  > 

<prim  sum  <var  i  1>  <var  1  2>>  >> 

<const  2>  <const  3>> 


"XT' 
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let  rec  Eval  =  oroc(e,a)  begin 

it  is-const(e)  then  const-val  (el 

elsit  is-var(e)  then  arFvpfe)!  where  ar  =  arep(e)1 
elsit  i s-lamhda ( e)  then  clQSure(  e,  a) 
elsit  is-prim(e)  then  apply-nrimF  rator(e),  actuals) 
where  actuals  =  evlis(  rands(e),  a) 
elsit  is-call(e)  then  apDlY(  closure,  actuals) 
where  closure  =  eval{  ratorCe),  a) 
and  actuals  =  evlis(  rands(e),  a) 
elsif  is-it(e)  then 

if  eval  (  cond(e),  a)  then  eval  (  t-branch  (e)  ,  a) 
else  eval{  c-branch(e),  a)  endif 
end  if  end 

and  rec  evlis  =  proc(L,a)  begin 
if  null(L)  then  <> 

else  cons  (  eval(L[n,a),  evlis  (rest  (L)  , a)  )  endif  end 

and  rec  apply  =  oroc (  closure,  actuals)  begin 
let  abs  =  ip(closure)  in 

let  env  =  consR{  ep(closure),  actuals)  in 
eval {  body  (abs),  env)  end 

and  apply-prim  =  proc(f,x)  begin 
if  f='first'  then  first(xril) 
elsif  f='Gons'  then  cons(  xFil ,  xr2]  ) 
elsif  ... 
endif  end 
in  ... 

and  consR  =  ptoc(L,x){  append  (  L,  CQns(x,<>)  )  } 

Figure  5.  Eval  for  Fixed-*Iocation  Variables 


Here  we  see  that  'x',  'y'  and  ' z'  have  been  translated  as  ' <var  1 
!>',  '<var  1  2>'  and  '<var  2  !>',  respectively,  on  the  basis  of 
their  static  nesting  levels  and  their  positions  at  that  level, 
i.e.  their  (ep,vp)  coordinates.  The  trace  follows: 
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£  ®  <'cali'  X  <<'consc’  2>  X'consc'  3>>  > 

X  =»  <'iambda’  <'caii'  Z  <3>>  > 

2  =*  <'iaKvbda'  X'ptim’  'sum'  <P  X'var'  i  i>>  >> 

S  *  <'ptin'  'sum'  <<'var'  i  i>  <'var'  i  2>>  > 

P  *  <'ptim'  'ptod'  <<'vac'  2  i>  <'vat:'  2  i>>  > 

Evai (  S ,  <>  ) : 

appiy(  <'ciGsar0'  X  <>  >,  <2  3>  ): 
env  =  GGnsR(  <>,  <2  3>  )  =  <<2  3>> 
evai(  <'caii'  Z  <S>>,  <<2  3>>  ): 
actuals  =  eviiS{  <<'prim'  'sum' 

<<'var'  1  i>  <’vat’  i  2>>  >>,  <<2  3>>  ) 
=  <  sum(2,3)  >  =  <5> 
apply!  <'clQ3ui:e'  Z  <<2  3>>  >,  <5>  ): 
env  =  consR(  <<2  3>>,  <5>  )  =  <<2  3>  <5>> 
aval!  X'ptim'  'sum*  <P  <'vac’  1  1>>  >,  <<2  3>  <5>>  ): 
actuals  *  evlis!  <P  <'vac'  1  1>>,  <<2  3>  <5>>  ) 

=  <  evai(P,<<2  3><5>>)  2  > 

It  is  new  necessary  to  compute  the  subexpt ess r on ,  eval!?,<<2 

3><5>>) . 

aval !  P,  <<2  3>  <5>>  ) ; 
actuals  =  aviis(  <<'va£'  2  i>  <'7at'  2  1>>, 

<<2  3>  <5>>  ) 

*  <5  5> 

prim-apply!  'prod',  <5  5>  )  “  25,  hence, 
actuals  =  <25  2> 

piim-apply!  'sum',  <25  2>  )  =27 

You  will  recall  that  there  were  two  possible  versions  of  the 
sinqie-'oarameter  'eval':  one  which  used  static  nesting  levels  and 
one  which  used  static  distances.  There  are  also  two  possible 
versions  of  the  multiple-parameter  version  of  'eval':  we  can  use 
either  static  nesting  levels  or  static  distances,  when  we  inves¬ 
tigate  implementations  of  the  lambda  calculus  further,  later,  we 
will  find  that  there  are  circumstances  when  it  is  better  to  use 
the  static  distance  and  other  circumstances  when  it  is  better  to 
use  the  static  nesting  level.  These  are  similar  to  imolementa- 
tion  techniques  called  "static  chains"  and  "d isolays " .  which  are 
discussed  later. 

EXERCISE ;  Translate  the  lambda  exoression 

>,xy{  >,2!  2*2  +  X  }  (x-t-y)  }  !2,3) 

into  the  list  reor esentation  using  static  distances  instead  of 
static  nesting  levels.  Make  the  aaprooriace  changes  to  'eval'  so 
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I  .5  Runtime  Oraanization 
I  .5.1  Goals  Pet  ined 

In  this  chapter  we  will  study  the  stack  implementation  ot 
the  extended  lambda  calculus.  That  is,  we  will  study  how  RLC  can 
be  translated  into  the  instructions  ot  conventional  computers  by 
using  the  data  structure  known  as  a  stack .  Rince  all  block- 
structured  lanouages,  when  striooed  ot  their  syntactic  sugar,  are 
essentially  the  lambda  calculus,  you  will  be  learning  how  to 
imolement  these  languages.  (This  imoortant  class  ot  languages 
includes  Algol,  Pascal,  PL/l  and  Ada.) 

I  .5  .  ■?  Stacks 

The  data  structure  used  on  most  computers  tor  implementina 
block-structured  languages  is  the  stack .  Stacks  derive  their 
name  from  the  push-down  stacks  that  are  often  used  for  disoensing 
plates  in  cafeterias  (figure  i)  . 


Figure  1.  The  Original  Push-Down  Stack 

With  these  devices,  each  time  a  olate  is  removed  from  the  too , 
the  stack  pops  up  to  bring  the  next  plate  to  the  too.  Con¬ 
versely,  whenever  a  plate  is  placed  on  the  too  of  the  stack,  it 
pushes  down  the  plates  already  there.  Thus,  a  particular  Plate 
can  be  pushed  onto  the  stack,  and  have  other  plates  pushed  on  too 
of  it,  thereby  hiding  it.  Rut  if  these  plates  are  later  popped 
off,  then  the  plate  we  started  with  will  again  be  at  the  too  of 
the  stack.  This  property,  being  able  to  save  things  (or  informa¬ 
tion)  by  pushing  them  on  a  stack,  makes  the  stack  data  structure 
particularly  valuable  in  programming  language  implementation. 
Stacks  are  also  know  as  push-down  stores ,  deques  and  LIF'Rs  (which 
means  "last-in,  first-out"  and  is  pronounced  "lie-foe").  To  see 
the  relevence  of  stacks  to  programming  language  implementation, 
we  must  next  investigate  postfix  instructions. 
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I  .5.3  °ostt  ix  Inscruccions 

'«'e  have  seen  how  exoressions  can  be  written  in  tunctional 
torm.  For  instance. 


X  +  ab(y-z) 


can  be  written 


sum(  X,  prod(  prodfa.b),  dif(y,z)  )) 

When  an  expression  such  as  this  is  written  without  parentheses  it 
is  call  prefix  notation  or  Polish  notation  (after  Jan  fe 
ukasiewicz,  the  Polish  loqician  who  invented  it).  The  above 
expression  written  in  prefix  notation  is: 

+  x**ab-*vz 

One  of  the  important  properties  of  Polish  notation  (and  the  rea¬ 
son  it  was  invented)  is  that  it  is  never  necessary  to  use 
parentheses  with  it;  it  is  ofen  called  parentheses  free  nota- 
tion . 


The  reason  Polish  notation  is  also  called  Prefix  notation  is 
that  the  operator  is  written  before  (pre-)  its  operands.  F.g, 

+  X  y 

The  usual  mathematical  convention  is  called  infix  notation 
because  the  operator  is  written  between  (in-)  its  operands: 

X  +  y 

It  should  be  obvious  that  if  we  wrote  the  operator  after  its 
operands,  then  we  would  be  writing  in  postfix  or  reverse  Polish 
notation.  Peverse  Polish  notation  is  more  important  to  computer 
scientists  than  Polish  notation  because  reverse  Polish  can  be 
evaluated  easily  by  using  a  stack. 

You  may  be  familiar  with  "PPM"  (or  Reverse  Polish  Notation) 
calculators,  such  as  those  manufactured  by  Hewl i tt-Packa rd  and 
National  Semiconductor,  with  these  calculators  expressions  to  be 
evaluated  are  entered  in  postfix  notation  and  temoorarv  results 
are  held  in  a  stack.  For  instance,  to  calculate 

2  +  5  *  in, 

which  is  postfix  notation  is 


2  S  10 


*  +, 
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we  would  hit  the  keys: 

m  cs:  ppwi  G3  m  cs  ce 

The  follwinq  diagram  shows  how  the  stack  holds  the  intermediate 
results. 


Notice  how  the  stack  holds  the  operands  before  the  oneration 
(e.g.  5  and  10)  and  the  results  after  the  operation  (e.g.  50). 


I  .5.4  The  L-^Mach ine  ^rch i tecture 

’''e  will  now  investigate  a  computer  with  a  stack  architec¬ 
ture,  i.e.  a  computer  that  uses  a  stack  for  the  evaluation  of 
postfix  instructions.  Although  the  L-Machine  is  not  a  real  com¬ 
puter,  it  is  essentially  a  simplification  of  several  commercially 
available  machines. 

The  L-Nachine  has  three  registers  (high  speed  memory  loca¬ 
tions)  ,  called  SP,  SP  and  IP,  and  a  memory  addressed  by  consecu¬ 
tive  natural  numbers  that  can  hold  both  data  and  instructions. 
The  register  names  are  mnemonic: 

SP  -  Stack  Pointer 

SP  -  Environment  Pointer 

IP  -  Instruction  Pointer 

The  SP  register  holds  the  address  of  the  top  of  the  stack,  the  SP 
register  holds  the  address  of  the  current  activation  record 
(explained  further  later)  and  the  IP  register  holds  the  address 
of  the  next  instruction  to  be  executed.  The  L-Nachine's  storage 
architecture  is  summarized  in  the  following  figure. 

Peaisters  Memory 


Figure  2.  L-^achine  Storage  Architecture 
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The  L-“Machine  has  some  25  instructions  that  it  is  able  to 
execute.  we  will  discuss  each  ot  these  in  the  tollowinq  para- 
qraphs  and  indicate  their  ooeration  with  diaqrams. 

1  PUSH .  The  'PUSH'  operation  pushes  a  constant  value 
onto  the  stack.  That  is,  it  k  is  any  constant  (i.e.,  number, 
strinq,  Soolean  or  list),  then  'PUSH  k'  will  increment  the  SP 
reqister  and  store  k  in  the  memory  location  addressed  by  SP.  In 
diaqramatic  form: 


Stack 


PUSH  k 

2  PUSHEP .  The  "PUSHEP"  operation  oushes  the  current  con-* 
tents  of  the  EP  reqister  onto  the  stack: 


PUSHEP 


3  POP.  The  'OOP'  instruction  discards  elements  from  the 
top  of  the  stack.  That  is,  'pQP  k'  will  pop  the  too  k  elements 
from  the  stack  and  discard  them.  E.q.. 


POP  3 


4  SETEP .  The  'SETEP'  operation  oops  a  value  from  the 
stack  and  places  it  in  the  EP  reqister. 


SETEP 


5  .  The  'mark*  operation  moves  the  current  contents 
of  the  SP  reqister  into  the  EP  reqister.  The  effect  of  this  is 
to  remember  the  location  of  the  current  top  of  the  stack. 
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MARK 


COPY .  The  'COPY'  operation  copies  a  value  from 
a  specified  location  of  the  stack,  and  places  it  on  too 
stack.  For  instance,  'COPY  3’  copies  the  value  that  is 
from  the  too  of  the  stack  and  pushes  it: 


within 
of  the 
third 


a 

(1) 

(2]  => 

r 

a 

(3) 

a 

(4) 

— 

COPY 

3 

7  SWAP .  The  'SWAP'  operation  exchanges  two  elements  of 
the  stack.  For  instance,  'SWAP  2,5'  swap'^  the  second  and  fifth 
elements  from  the  top  of  the  stack: 


(i) 

a 

(2) 

b 

(3) 

(4^ 

b 

(■5) 

a 

(^) 

_ 

- 

SWAP  2,5 

S  PAIR.  The  'PAIR'  operation  combines  the  top  two  stack 
elements  into  one;  the  two  elements  become  the  left  and  right 
halves  of  the  resulting  value.  These  two  values  can  be  extracted 
by  'LEFT'  and  'RIGHT',  described  below. 


PAIR 
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9  Li^FT ,  RIGHT.  The  'LEFT'  operation  extracts  the  lett 
halt  ot  a  value  constructed  by  ’PMR': 


LEFT 


The  'RIGHT'  operation  extracts  the  right  half. 

.10  VAL .  The  'VAL'  ooeration  access  the  current  contents 
of  a  location  in  memory.  The  *VAL'  operation  takes  an  address 
from  the  top  of  the  stack  and  reolaces  it  with  the  contents  of 
the  memory  location  at  that  address. 


a 


11  'SET* 
of  a  memory  location  to  a 
an  address  from  the  top  of 
memory  location  with  that 
of  the  stack. 


operation  changes  the  current  conte 
soecified  value.  It  takes  a  value 
the  stack  and  stores  the  value  in 
address.  The  value  is  left  on  the 


nts 

and 

the 

top 


j 


Stack> 


''lemo  ry- 


12  ADD,  Stjq ,  MUL ,  OIV.  These  ooeranions  oertorm  addi- 
cion,  subtraction ,  multiolicacion  and  division.  The  operands  are 
the  two  top  elements  of  the  stack,  which  are  replaced  by  the 
results  of  the  operation.  This  is  essentially  like  an  RPN  calcu¬ 
lator. 


ADD 

(SUB,  MUL,  DIV  similar) 


Any  other  primitive  operations  with  which  we  wish  to  equip  the 
L-Machine  (such  as  the  relationals,  SO,  ME,  GT,  etc.)  would 
operate  analogously. 

13  The  'T'^'  operation  performs  a  iump  if  the  too  of 
the  stack  is  'true'.  In  particular,  the  operation  k'  pops 
the  stack  and,  if  this  value  is  'true',  transfers  to  the  instruc¬ 
tion  at  location  k  (by  placing  k  in  the  IP  register).  If  the  too 
of  the  stack  is  false  then  execution  continues  at  the  instruction 
which  follows  the  'IF'. 


M  => 


c=k  if  b=true 
c=a  it  b=faise 
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14 


;oTo . 


The 


''lOTO'  ooe  ration  cransters  cOncro' 


to 


another  location  by  olacinq  its  operand  in  the  IP  reqister 


TP 


=  >  TP 


qoTO  k 


15  qoi .  The  '''.01'  operation  is  an  "indirect  goto 
is,  the  top  or  the  stack  is  a  value  that  is  used  as  the 
ot  the  next  instruction  to  execute.  This  is  accomplished 
ping  the  stack  into  the  IP  reqister.  'TOT  is  used  instead 
when  the  destination  address  must  he  computed  while  the 
is  running. 


.  That 
address 
bv  pop- 
ot  GOTO 
oronram 


I  ,5.5  SiCt  i  vat  ion  Pecord  Structure  ^s  we  learned  in  Chapter  I.^ 
the  activation  record  is  the  implementation  mechanism  that  embo* 
dies  the  idea  of  the  local  environment  of  a  computation.  Activa¬ 
tion  records  will  also  be  important  to  our  compiled  implementa¬ 
tion  of  the  lambda  calculus,  so  in  this  section  we  will  study 
their  implementation  on  a  stack.  You  will  remember  that  we 
defined  an  activation  record  to  be  all  of  the  information 
relevant  to  a  call  of  a  procedure.  In  the  Pval  interpreter  this 
was  just  the  values  of  the  bound  variables  of  the  function.  ve 
will  see  below  that  in  the  compiled  implementation  additional 
information  must  be  included  in  the  activation  record. 

'"onsider  the  following  lambda  expression,  which  we  have 
already  investigated  several  times: 

let  i  =  3  in 

let  f  =  proc(x)f  x*i  }  in 
let  i  =  2  in 
f  (i) 

This  can  be  represented  by  the  contour  diagram  in  figure  3.  In 
this  diagram  we  have  drawn  solid  arrows  from  each  contour  to  the 
statically  enclosing  contour.  These  arrows  are  called  stat ic 
links.  A  static  chain  is  any  contiguous  sequence  of  static 
links,  for  instance  from  the  i=2  contour  to  the  f=>{xi}  contour 
to  the  i=3  contour,  what  the  static  chain  provides  is  a  search 
path  for  looking  up  variables.  For  instance,  if  we  are  executing 
in  the  environment  indicated  by  the  in  the  above  diagram,  and 
wish  to  evaluate  'i',  then  we  proceed  as  follows.  '^irst  look  in 


’^igure  3. 


Contours 


the  local  environment:  is  it  defined  here?  Mo,  only  'x'  is 
defined  here,  so  follow  the  static  link  to  the  enclosing  environ¬ 
ment:  is  it  defined  here?  Yes,  the  value  of  'i'  is  3  .  If  it 
hadn’t  been  defined  here  we  would  have  followed  the  static  link 
and  continued  searching  in  the  staticallv  enclosing  environment. 

In  our  compiled  imolenentation  of  the  lambda  calculus, 
activation  records  will  be  stored  in  a  stack,  we  will  use  static 
links  to  find  our  wav  from  one  activation  record  to  the  next, 
p'or  instance,  when  we  begin  executing  ’f(i)'  in  contour  (c)  ,  the 
stack's  structure  will  be: 


The  activation  records  correspond  exactly  to  the  contours  encoun¬ 
tered  in  following  the  static  chain  from  'f(i)'.  The  SP  register 
always  points  to  the  beginning  of  the  static  chain.  Mow,  suppose 
we  call  the  function  bound  to  'f'.  This  amounts  to  entering  the 
contour  (d  )  to  execute  'x*i'.  The  activation  record  tor  'f'  will 
be  pushed  onto  the  top  of  the  stack.  Mote,  however  that  the 
static  chain  reflects  the  correct  environment  for  ’x*i'; 


i^igure  5.  Inside  f 


In  oarticular,  when  we  come  to  evaluate  'i',  we  will  tollow  the 
static  chain  to  activation  record  (a),  which  binds  'i'  to  3. 
When  the  function  'f'  is  exited  the  activation  record  (d)  must  be 
deleted  from  the  stack  and  the  situation  restored  to  that  of  fig¬ 
ure  4.  To  do  this  it  is  necessary  to  regain  access  to  activation 
record  (c) ,  the  activation  record  of  the  caller  of  'f'.  Doing 
this  requires  another  link,  the  dynamic  link,  from  each  activa¬ 
tion  record  to  its  caller.  The  sequence  of  dynamic  links  is 
called  the  dynamic  chain .  In  figure  ^  we  see  the  same  situation 
as  in  figure  5  (i.e.  inside  f)  exceot  that  the  dynamic  chain  is 
shown . 
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Mocice  chat  the  dynamic  link  always  points  to  the  next  lower 
activation  record  in  the  stack. 

'5o  tar  we  have  seen  that  the  activation  record  contains 
three  nieces  ot  information:  the  values  of  the  bound  variables, 
the  static  link  and  the  dynamic  link.  There  is  one  other  type  ot 
information  that  is  useful  to  include  in  the  activation  record: 
temporaries,  wt^en  we  discussed  the  stack  evaluation  of  posttix 
exnressions  we  saw  that  the  stack  holds  onerands  until  it  is  time 
to  onerate  on  them.  We  will  use  the  stack  for  the  same  nuroose 
here. 

The  actual  format  we  will  adopt  for  activation  records  is 
not  the  same  as  we  have  investigated  so  far.  The  differences  are 
not  imnortant,  however;  we  have  merely  reorganized  the  fields  of 
the  activation  record  to  make  it  more  convenient  to  access  them 
with  the  instructions  of  the  L-Machine.  If  we  were  compiling  the 
lambda  calculus  for  some  other  machine  then  some  other  arrange¬ 
ment  might  be  better.  The  important  thing  is  the  information  the 
activation  record  contains,  irresnective  of  its  arrangement: 

*  access  to  local  environment  (values  of  bindings) 

*  access  to  olobal  environment  (static  link) 

*  access  to  caller  (dynamic  link) 

*  temporaries 

This  information  must  be  in  any  activation  record.  The  format  we 
will  use  for  the  L-'iachine  is  shown  in  figure 


temocrar ies 


static  link 
dynamic  link 

I 

e  m  ;  i  o 
oar ameter  FT 


oarameter  1 


Stack-^ 

'='igure  .  Activation  Record  Format 
I  .5  Translation  to  L-Code 


Tn  this  section  we  will  discuss  the  L-'Code  (L-Machine 
instruction)  translations  for  each  construct  in  the  extended 
laTibda  calculus.  To  aid  this  discussion  we  will  use  the  notation 
Ale]  to  denote  the  L-Code  translation  ot  the  lambda  exoression  e. 
For  instance, 

Af  25  1  =  P'J5H  25 

The  translations  we  will  investiqate  in  the  rest  of  this  section 
are  not  unique;  different  machines  would  suqqest  ditferent  code 
sequences;  there  are  even  different  ways  on  accomplishing  the 
same  thing  on  the  L-“Machin9.  The  important  issue  is  not  the  par¬ 
ticular  instructions  presented  here,  but  rather  the  information 
flow  required  to  execute  the  lambda  calculus  constructs.  Since 
the  lambda  calculus  forms  a  deep  structure  for  most  programming 
languages  we  are  essentially  studying  the  implementation  methods 
ror  most  programming  languages. 

1  Constants  The  translation  of  variables  is  the  sim¬ 
plest,  since  all  we  have  to  do  is  to  push  the  constant  on  the 
stack.  For  instance, 

Af25]  =  PUSH  25 

/.('hat']  =  PUSH  'hat' 

A(<1  k'hat'  2>>]  =  PUSH  <1  <'hat'  2>> 

or  in  general,  for  any  constant  c. 

Ate]  »  PUSH  c 

2  Variables  In  the  discussion  of  the  Fval  interpreter  we 

saw  the  use  of  (eo,vp)  pairs  to  locate  variables  within  the 
environment.  We  will  do  the  same  with  our  compiled  implementa¬ 
tion:  the  ep  will  locate  the  activation  record  holding  the  vari¬ 

able  and  the  vp  will  locate  the  variable  within  that  activation 
record.  The  static  distance  method  of  measuring  the  eo  will  be 
used  . 


First,  consider  how  we  get  to  the  activation  record  in  which 
the  variable  resides:  if  eD=l  then  the  variable  resides  in  the 
current  activation  record,  which  is  pointed  to  by  the  FP  regis¬ 
ter.  If  eo=2  then  the  variable  resides  in  the  next  most  enclos¬ 
ing  activation  record,  which  we  reach  by  followina  one  link  ot 
the  static  chain  form  the  current  activation  record.  It  eo=3 
then  we  must  follow  two  links  of  the  static  chain.  In  general, 
we  must  follow  ep-i  links  to  get  to  the  activation  record  con¬ 
taining  variable  (eD,vp). 

Now  let  us  consider  the  L-Code  required  to  follow  the  static 
chain.  Our  goal  will  be  to  get  the  address  of  the  activation 


recorcl  eo  onto  the  top  ot  the  stack.  Considei  the  case  ep=l.  In 
this  case  the  activation  record  is  the  current  one,  so 

PUSHEP 

will  push  its  address  onto  the  stack. 

Now  consider  the  case  eD=^;  here  we  must  follow  the  static 
chain  one  link.  Recall  that  both  the  EP  reqistd'  and  the  static 
links  always  point  to  the  static  link  field  of  an  activation 
record.  See  figure  8. 


Figure  8.  The  Static  Chain 

Hence,  after  performing  PUSHEP  the  top  of  the  stack  is  the 
address  of  the  static  link  for  the  current  activation  record.  We 
can  use  VAL  to  load  the  contents  of  this  location,  i.e.  to  get 
the  address  of  the  next  activation  record  in  the  static  chain. 
Hence , 

PUSHEP 

VAL 

will  leave  on  the  top  of  the  stack  the  address  of  the  eD=?. 
activation  record. 

Following  the  same  reasoning  we  can  see  that  if  eD=3  then 
the  address  of  the  activation  record  is  computed  by: 

PUSHEP 

VAL 

VAL 

In  general,  the  code  to  access  the  activation  record  at  static 
distance  ep  is  PUSHEP  followed  by  ep-i  VALs.  We  will  write  this: 


P'JSHEP 

(ep-1)  *  {  VSiL 

’''e  have  seen  how  to  use  the  ep  oart  ot  a  variable's  coordinates 
to  qet  to  the  activation  record  in  which  it  resides.  We  will  now 
investiqate  the  use  of  the  vo  part  to  locate  the  variable  within 
that  activation  record.  ^iqure  9  shows  an  activation  record  with 
several  measurements  indicated. 


If  base  is  the  base  address  of  the  activation  record  (i.e.  the 
address  of  its  static  link)  then 

base-3-n-vp 

is  the  address  of  the  vo-th  variable  in  that  activation  record. 
We  can  rewrite  this  as 

base  -  (2+n-vp) 

Notice  that  (2+n-vp)  is  a  constant  that  depends  only  on  the  vp 
coordinate  of  the  variable  and  the  number  of  variables  bound  at 
lexical  level  ep.  We  will  call  this  latter  quantity  and 

define  ^ 

6(ep,vp)  =  P.+ngp-vn 

Thus  the  address  of  the  variable  with  coordinates  (eD,vp)  is 

basegp-6 (ep,vp) 

It  is  very  easy  for  a  compiler  to  compute  the  quantity  6(ep,vp); 
it  need  only  keen  track  of  the  number  of  variables  declared  at 
each  lexical  level. 
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Now  we  are  ready  zo  nut  toqether  the  two  narts  of  the  vari¬ 
able  accessing  mechanism.  To  get  the  address  of  variable  feD,va) 
we  need  basegp,  the  address  of  the  activation  record  at  static 
distance  ep.  This  is  exactly  what  is  computed  by; 

P'JSHEP 

(eo-i)  *  {  VAL 

To  get  the  address  of  the  variable  we  must  subtract  $(ep,vp); 

P'J'?H  6  (en,vD) 

SUB 

Therefore  the  code  for  accessing  the  variable  with  coordinates 
(eD,vp)  and  leaving  its  value  on  the  stack  i.‘: 

Va r  eo , vp  = 

PUSHEP 

(ep-1)  *  {  V^L 

PUSH  6  ( ep , vp) 

SUB 

7AL 

'"'e  have  given  this  sequence  of  instructions  the  "macro"  name  Var 
because  it  occurs  so  frequently.  Macros  like  this  are  sometimes 
called  code  skeletons .  *’or  example,  if  the  coordinates  for  'x' 
are  (3,2)  and  03=3  then  the  code  for  accessing  'x'  is: 

AIx)  =  ^3,2  = 

PUSHEP 

V2^L 

VAL 

PUSH  3 

SUB 

VAL 

since  ^(3,2)  =  2+n3-2  =  2+3-2  =  3. 

It  must  be  emphasized  again  that  the  L-Code  shown  here  is 
appropriate  to  the  activation  record  format  we  have  chosen.  If 
the  activation  record  format  were  different,  then  dirferent 
instructions  would  be  required.  The  important  ideas  to  remember 
in  accessing  a  variable  with  coordinates  (eD,vp)  are; 

1)  Bind  the  activation  record  holding  the  variable  by  fol¬ 
lowing  the  static  chain  for  a  static  distance  of  eo. 

2)  Use  the  vo  coordinate  to  access  the  variable  within 
activation  record  found  in  step  (i). 


the 
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We  can  now  state  the  translation  rule  for  a  variable  'v' 
with  coordinates  (eD,vp): 

A(v)  =  Var  en,vD 

3  Applications 

Recall  that  the  steps  involved  in  evaluating  a  application 

are: 

1)  Evaluate  the  operator. 

2)  Evaluate  the  operands. 

3)  Construct  the  environment  of  evaluation. 

4)  Evaluate  the  body  of  the  function  in  this  environment. 

The  code  that  we  produce  for  a  application  will  have  to  perform 
these  same  steps.  It  is: 

A(  f  (e^  ,  .  ,  .  ,6^.)  ] 

Atfl 


n 


The  Call  macro  instruction  will  do  the  work  of  constructing  an 
activation  record  for  the  new  environment  and  executing  the  func¬ 
tion  in  that  environment  (steps  (3)  and  (4)). 


EXAMPLE :  Compile  'mod  (7, '3)'.  Assume  the  coordinates  of 
'  mod '  are  ( 3  , 1 )  • 


A[  mod(7,2)  ]  = 


A(mod] 

A(7} 

At21 

Call  2  = 

Var  3,1 
P'JSH  7 
PUSH  2 
Call  2 

As  noted  above,  the  Call  macro  instruction  is  responsible  for 
building  the  new  activation  record  and  for  entering  the  pro¬ 
cedure.  Since  the  parameter  values  are  already  stacked,  only  the 
dynamic  and  static  link  parts  of  the  new  activation  record  remain 


# 


i 
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CO  be  constructed.  The  steps  are; 

1)  Construct  dynamic  link. 

2)  Construct  static  link. 

.1)  Install  the  new  current  activation  record. 

4)  Enter  the  function. 

■^ince  the  dynamic  link  must  oreserve  the  state  of  the  caller  it 
has  two  parts:  an  eo  to  preserve  the  caller's  environment  and  an 
ip  to  oreserve  the  next  instruction  to  execute.  These  can  be 
saved  by  constructing  a  closure: 

PUSHEP 
PUSH  r 
PAIR 

where  r  is  the  address  of  the  next  instruction  following  Call; 
this  is  where  execution  of  the  caller  will  resume  when  the  called 
procedure  returns.  This  leaves  the  stack  in  the  state: 

1 
2 


n+1 
n+2 

The  static  link  must  point  to  the  environment  of  definition  of 
the  procedure.  As  the  above  diagram  indicates,  the  (n+2)  posi¬ 
tion  from  the  too  of  the  stack  contains  a  closure  for  the  pro¬ 
cedure  to  be  called  (this  resulted  from  evaluating  the  operator 
in  steo  (1)).  The  static  link  is  constructed  by  extracting  the 
left  half  (eo)  of  this  closure: 

COPY  n+2 
LEFT 

The  third  step,  installing  the  new  current  activation  record,  is 
accomplished  by  placing  the  address  of  the  new  activation  record 
into  the  FP  register.  Since  the  static  link  is  currently  at  the 
top  of  the  stack,  this  is  accomplished  by: 

MARK 


This  leaves  the  stack  in  the  state: 


67 


1 

2 

3 


n+2 

n+3 


and  comoletes  construction  or  the  activation  record. 

The  fourth  step  is  to  enter  the  function.  The  address  of 
the  first  instruction  in  the  function  is  contained  in  the  closure 
at  position  (n+3)  in  the  stack.  Thus  transfer  into  the  function 
is  accomplished  by: 

COPY  3+n 

RICHT 

GOI 


Puttinq  together  the  entire  instruction  sequence  for  Call  yields: 


Call  n  = 
PURHRP 
PUSH  r 
PMR 

COPY  n+2 

L5FT 

M^RK 

COPY  n+3 

RIGHT 

GOI 


1 

}  build  DL 
I 

}  build 
}  SL 

}  install  new  ^R 
}  get  entry 
}  point 

>  enter  the  function 
}  the  return  location 


It  is  to  he  emphasized  again  that  the  specific  code  sequence 
shown  above  is  not  so  important  as  the  general  steps  involved  in 
a  call: 


1)  Save  the  state  of  the  call  in  the  dynamic  link. 

2)  Make  the  static  link  from  the  ep  in  the  closure. 

3)  Snter  the  function  at  the  location  determined  by  the 
ip  of  the  closure. 


5XERCISS :  Oesiqn  the  activation  record  format  for  a  computer  with 
which  you  are  familiar.  Write  the  sequence  of  instructions 
necessary  to  do  a  Call  on  this  machine. 

4  Abstractions 


Recall  that  in  the  Eval  interpreter  the  proper  execution  of 
an  abstraction  was  ensured  by  packaging  it  together  with  its 


environment  into  a  closure .  In  the  compiled  case  the  eo  part  ot 
a  closure  is  a  pointer  to  the  activation  record  of  definition  and 
the  ip  part  is  the  address  of  the  first  instruction  on  the  code 
for  the  abstraction's  body.  T’his  is  constructed  by: 

P'JSHFIP 
PUSH  k 
PMR 

where  'k'  is  the  entry  address  of  the  function.  The  body  of  an 
abstraction  '^V’ • • • Vp{ e } '  is  translated  to: 

k  : 

Return  n 

where  Return  is  a  "macro"  instruction  described  below.  Since  we 
do  not  want  the  function  body  to  be  executed  before  it  is  called, 
we  must  jump  over  it.  Therefore,  the  translation  of  an  abstrac¬ 
tion  is: 

.  .  "  Vp^{  E )  ]  = 

PUSHEP  ep  I 

PUSH  k  ip  } 

PMR  I 

'lOTO  s  } 

k.-Af"} 

Return  n 
s : 

The  Return  instruction  must  accomplish  the  following  tasks: 

1)  Pass  the  r eturned-value  from  the  callee  to  the  caller. 

2)  Restore  the  state  of  the  caller  from  the  dvnamic  link. 

3)  Delete  the  callee's  activation  record. 


build  closure 
skip  body 


The  state  of  the  stack  before  the  Return  is: 


1 

2 

3 

4 


n+3 

n+4 


The  r eturned-value  ('answer'  in  the  above  diagram)  can  be  placed 
above  the  caller's  temporaries  and  two  words  of  the  activation 
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record  deleted  by; 

SWAP  i,n+4 
POP  2 

The  environment  ot  the  caller  is  restored  by: 

COPY  1 

LfJFT 

SRTEP 


leaving  the  stack  in  the  form; 


The  address  to  which  to  return  to  the  caller 
the  dynamic  link  and  saved  above  the  answer 


is  extracted 
in  the  stack  by; 


from 


RIGHT 

SWAP  l,n+l 
POP  n 


The  'POP  n'  instruction  deletes  the  n  oarameter  values,  exposing 
the  return-address  for  a  GOI  back  to  the  caller.  The  resulting 
code  is; 


Return  n  = 
SWAP  l,n+4 
POP  2 
COPY  1 
LEFT 
SETEP 
RIGHT 

SWAP  l,n+l 
POP  n 
GOI 


}  save  answer 
}  delete  closure,  SL 
1 

}  restore  EP  from  DL 
I 

}  get  return  address  from  OL 
}  save  return  address 
}  delete  parameters 
}  reenter  caller 


5  Conditionals 


The  compiled  L-Code  for  handling  conditionals  will  operate 
similarly  to  the  Eval  interpreter.  That  is,  for 

r  B  ->  T  1  F  1 


we  must  first  evaluate  B  and  if  it  is  true  evaluate  T, 


otherwise 
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evaluate  F.  The  translation  to  accomolish  this  is: 

AI  [  8  T  I  F  1  1  = 

A(B] 

IF  t 
AtFl 
'^OTO  X 
t:  ACT] 
x: 

■S  Slocks 

In  section  1,4,20  we  saw  that  the  erticiency  of  blocks 
(local  declarations)  could  he  improved  by  implementing  them  in 
Fval  directly,  rather  than  as  procedure  invocations.  The  same  is 
true  with  respect  to  the  L-Code  implementation  of  blocks,  since  a 
simpler  activation  record  structure  will  suffice  and  since  it 
will  not  be  necessary  to  construct  or  decompose  closures. 
Indeed,  since  a  block  is  always  invoked  in  its  environment  of 
definition,  its  static  and  dynamic  links  are  always  the  same. 
Further,  since  a  block  is  always  invoked  from  the  same  place,  it 
is  not  necessary  to  save  the  IP  of  the  caller.  Although  this 
means  that  these  items  could  be  omitted  entirely  from  the  activa¬ 
tion  record  for  blocks,  we  will  include  space  for  them  so  that 
the  format  will  agree  with  that  of  a  procedure's  activation 
record.  This  will  allow  us  to  use  the  translation  of  variables 
already  discussed  regardless  of  whether  the  variable  was  bound  by 
a  procedure  or  a  block.  In  an  actual  compiler  we  might  choose  to 
use  two  different  formats  at  the  expense  of  a  more  complicated 
translation  process. 

With  this  explanation  done  we  can  proceed  with  the  transla¬ 
tion  of  blocks.  This  makes  use  of  two  "macro"  instructions  which 
create  and  delete  the  block's  activation  record: 

Allet  v-^=e2  and  and  Vn=eri  ” 

Are^l 


Begin 

AtB) 

Fnd  n 

The  Begin  and  Fnd  instructions  are  simplifications  of  Call  and 
Beturn : 
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!^eqin  = 

PIJSH'=:p  }  eo  }  build  OL 

PUSHPP  }  '^L 

MARK  }  install  new  current  AR 

Pnd  n  = 

SWAP  1,3+n  1  save  answer 
POP  2  }  delete  first  local  and  SL 

}  restore  EP 
SETEP  ]  from  DL 

POP  n-1  }  discard  rest  of  locals 
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